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: Heikki Linnakangas on 24 Feb 2010 12:18 Kevin Grittner wrote: > With the "simplifying" technique of keeping the leaf level in a > separate file, it becomes hard to distinguish from Heikki's Grouped > Index Tuples approach when you include the "maintain cluster order" > patch. That really looks like where anyone should work from for any > IOT effort. It appears to have been largely completed years ago. > > For those who missed or forgot it, this is the latest I could find: > > http://community.enterprisedb.com/git/ > > Heikki, any thoughts on what it would take, beside cleaning up bit > rot? There was discussion on the indexam API changes required, I don't recall the details right now. -- Heikki Linnakangas EnterpriseDB http://www.enterprisedb.com -- 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: Greg Stark on 24 Feb 2010 12:23 On Wed, Feb 24, 2010 at 4:12 PM, Gokulakannan Somasundaram <gokul007(a)gmail.com> wrote: > Sequential scans can be done on IOTs, just scan through the leaf pages. That doesn't work because when you split an index page any sequential scan in progress will either see the same tuples twice or will miss some tuples depending on where the new page is allocated. Vacuum has a clever trick for solving this but it doesn't work for arbitrarily many concurrent scans. -- 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: "Kevin Grittner" on 24 Feb 2010 12:33 Greg Stark <gsstark(a)mit.edu> wrote: > Gokulakannan Somasundaram <gokul007(a)gmail.com> wrote: >> scan through the leaf pages. > > That doesn't work because when you split an index page any > sequential scan in progress will either see the same tuples twice > or will miss some tuples depending on where the new page is > allocated. Vacuum has a clever trick for solving this but it > doesn't work for arbitrarily many concurrent scans. It sounds like you're asserting that Index Scan nodes are inherently unreliable, so I must be misunderstanding you. -Kevin -- 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: Simon Riggs on 24 Feb 2010 12:35 On Wed, 2010-02-24 at 15:52 +0000, Greg Stark wrote: > We can do > better with stuff like Heikki's "grouped index tuple" and the > visibility map which don't interfere with other features as much. Yes, much better plan. More practical, nearly there. -- Simon Riggs www.2ndQuadrant.com -- 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 24 Feb 2010 12:46
"Kevin Grittner" <Kevin.Grittner(a)wicourts.gov> writes: > Greg Stark <gsstark(a)mit.edu> wrote: >> That doesn't work because when you split an index page any >> sequential scan in progress will either see the same tuples twice >> or will miss some tuples depending on where the new page is >> allocated. Vacuum has a clever trick for solving this but it >> doesn't work for arbitrarily many concurrent scans. > It sounds like you're asserting that Index Scan nodes are inherently > unreliable, so I must be misunderstanding you. We handle splits in a manner that insures that concurrent index-order scans remain consistent. I'm not sure that it's possible to scale that to ensure that both index-order and physical-order scans would remain consistent. It might be soluble but it's certainly something to worry about. 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 |