On 4/21/15 10:04 AM, Bruce Momjian wrote:
One thing to consider is how we handle pruning of index scans that hit multiple heap pages. Do we still write X% of the pages in the table, or %X of the heap pages we actually access via SELECT? With the write-then-skip approach, we would do X% of the pages we access, while with the first-X% approach, we would probably prune all of them as we would not be accessing most of the table. I don't think we can do the first first-X% of pages and have the percentage based on the number of pages accessed as we have no way to know how many heap pages we will access from the index.
This comment made me wonder... has anyone considered handing the pruning work off to a bgworker, at least for SELECTs? That means the selects themselves wouldn't be burdened by the actual prune work, only in notifying the bgworker. While that's not going to be free, presumably it's a lot cheaper...
-- Jim Nasby, Data Architect, Blue Treble Consulting Data in Trouble? Get it in Treble! http://BlueTreble.com -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
