Robert Haas escribió: > On Wed, Sep 25, 2013 at 4:34 PM, Alvaro Herrera > <alvhe...@2ndquadrant.com> wrote: > > Here's an updated version of this patch, with fixes to all the bugs > > reported so far. Thanks to Thom Brown, Jaime Casanova, Erik Rijkers and > > Amit Kapila for the reports. > > I'm not very happy with the use of a separate relation fork for > storing this data.
I understand this opinion, as I considered it myself while developing it. Also, GIN already does things this way. Perhaps I should just bite the bullet and do this. > Using an existing fork number rather than creating > a new one avoids some of them (like, the fact that we loop over all > known fork numbers in various places, and adding another one will add > latency in all of those places, particularly when there is a system > call in the loop) but not all of them (like, what happens if the index > is unlogged? we have provisions to reset the main fork but any others > are just removed; is that OK?), and it also creates some new ones > (like, files having misleading names). All good points. Index scans will normally access the revmap in sequential fashion; it would be enough to chain revmap pages, keeping a single block number in the metapage pointing to the first one, and subsequent ones are accessed from a "next" block number in each page. However, heap insertion might need to access a random revmap page, and this would be too slow. I think it would be enough to keep an array of block numbers in the index's metapage; the metapage would be share locked on every scan and insert, but that's not a big deal because exclusive lock would only be needed on the metapage to extend the revmap, which would be a very infrequent operation. As this will require some rework to this code, I think it's fair to mark this as returned with feedback for the time being. I will return with an updated version soon, fixing the relation fork issue as well as the locking and visibility bugs reported by Erik. -- Álvaro Herrera 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