On 8 August 2014 16:03, Heikki Linnakangas <hlinnakan...@vmware.com> wrote:
> I couldn't resist starting to hack on this, and implemented the scheme I've > been having in mind: > > 1. MMTuple contains the block number of the heap page (range) that the tuple > represents. Vacuum is no longer needed to clean up old tuples; when an index > tuples is updated, the old tuple is deleted atomically with the insertion of > a new tuple and updating the revmap, so no garbage is left behind. > > 2. LockTuple is gone. When following the pointer from revmap to MMTuple, the > block number is used to check that you land on the right tuple. If not, the > search is started over, looking at the revmap again. Part 2 sounds interesting, especially because of the reduction in CPU that it might allow. Part 1 doesn't sound good yet. Are they connected? More importantly, can't we tweak this after commit? Delaying commit just means less time for other people to see, test, understand tune and fix. I see you (Heikki) doing lots of incremental development, lots of small commits. Can't we do this one the same? -- Simon Riggs http://www.2ndQuadrant.com/ PostgreSQL Development, 24x7 Support, Training & Services -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
