A thought on Index Organized Tables
in [PgSql]
|
Prev: [COMMITTERS] pgsql: Oops, don't forget to rewind the directory before scanning it to
Next: Time travel on the buildfarm
From: Gokulakannan Somasundaram on 26 Feb 2010 09:38 > > > Much better to take on a "simple" project like enabling full > sequential index scans which you claimed you had a solution for and > which is in any case an important sub-problem for IOT. > > > Greg, Well i don't think i am ready to take up a project of this size. But at the same time some important features are lagging in postgres and someone should start working on them to make the database compete with other databases effectively. So i would request people like Tom, Heikki, Simon and you to take up a major project like this and provide the necessary impetus to the adoption of the database. I have never written much code in C, and even if write it, i am sure i will receive the comment that it is a unmaintainable code.(eg: Thick index code and trailing nulls code) So its better i start working with one of you guys to get a hang of developing maintainable code. So i would request one of you to initiate the development and provide the necessary directions to me, if possible. That will save my development effort and your reviewing effort. At the sametime, features like IOT, index only scans are features which are very necesary for postgres to atleast make it get inside my company. So i am putting forward all my arguments as a DB user. Thanks, Gokul.
From: Greg Stark on 26 Feb 2010 10:33 On Fri, Feb 26, 2010 at 2:38 PM, Gokulakannan Somasundaram <gokul007(a)gmail.com> wrote: > I have never written much code in C, and even if write it, i am > sure i will receive the comment that it is a unmaintainable code.(eg: Thick > index code and trailing nulls code) I definitely think thick indexes were too ambitious of a target for a first time patch. Sequential index scans is very ambitious itself despite being significantly simpler (if you have a solution which works -- we haven't had one thus far). Can you point me to the thread on "trailing nulls"? I think trimming off any null columns from the ends of tuples when forming them should be a cheap and easy optimization which just nobody's gotten around to doing. If that's what you mean then I'm surprised you had any trouble getting buy-in for it. -- greg -- Sent via pgsql-hackers mailing list (pgsql-hackers(a)postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
From: Tom Lane on 26 Feb 2010 10:47 Greg Stark <gsstark(a)mit.edu> writes: > On Fri, Feb 26, 2010 at 4:47 AM, Tom Lane <tgl(a)sss.pgh.pa.us> wrote: >>> I feel the other one is easy. To store the hint bits inside the ItemId, in >>> the place of size. >> >> No, we're not going there. > Well we were already talking about moving the hint bits to someplace > else to enable CRC checking. My favourite place was the line pointer, > but you wanted a separate area -- either of which would have these > problems. IIRC, what was being talked about was shoehorning some hint bits into the line pointers by assuming that size and offset are multiples of 4. I'm not thrilled with having mutable status bits there for reliability reasons, but it could be done without breaking a lot of existing code. What I was reacting to above was a suggestion that we could delete the itempointer size field altogether, which seems unworkable for the reasons I mentioned. regards, tom lane -- Sent via pgsql-hackers mailing list (pgsql-hackers(a)postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
From: Gokulakannan Somasundaram on 26 Feb 2010 13:30 Missed the group.. On Sat, Feb 27, 2010 at 12:00 AM, Gokulakannan Somasundaram < gokul007(a)gmail.com> wrote: > > I definitely think thick indexes were too ambitious of a target for a >> first time patch. Sequential index scans is very ambitious itself >> despite being significantly simpler (if you have a solution which >> works -- we haven't had one thus far). >> > > The point, i am trying to bring out is that i want to work with one of the > senior persons of the community to do my first few patches. > > >> >> Can you point me to the thread on "trailing nulls"? I think trimming >> off any null columns from the ends of tuples when forming them should >> be a cheap and easy optimization which just nobody's gotten around to >> doing. If that's what you mean then I'm surprised you had any trouble >> getting buy-in for it. >> >> http://archives.postgresql.org/pgsql-hackers/2008-03/msg00682.php > I think, the buy-in became difficult because of the code quality. > > > Thanks, > Gokul. > >
From: Gokulakannan Somasundaram on 26 Feb 2010 13:54
> IIRC, what was being talked about was shoehorning some hint bits into > the line pointers by assuming that size and offset are multiples of 4. > I'm not thrilled with having mutable status bits there for reliability > reasons, but it could be done without breaking a lot of existing code. > What I was reacting to above was a suggestion that we could delete the > itempointer size field altogether, which seems unworkable for the > reasons I mentioned. > I think then we can pursue on using the IndexTuple structure similar to HeapTuple(as you have suggested in an earlier update). This would involve(i believe) a) Making the current IndexTuple into IndexTupleHeader b) Creating a new structure called IndexTuple which will store the size and the have a pointer to IndexTupleHeader. But Tom, can you please explain me why that broken ordering example doesn't affect the current index scans. Thanks, Gokul. |