On Tue, Nov 22, 2016 at 8:45 PM, Tom Lane <t...@sss.pgh.pa.us> wrote: > Peter Geoghegan <p...@heroku.com> writes: >> The best thing by far about an alternative design like this is that it >> performs *consistently*. > > Really? I think it just moves the issues somewhere else.
Definitely, yes. * HOT is great and all, but HOT-safety is a pretty onerous thing to ask users to worry about. They don't know anything about it. Maybe WARM eventually helps with this -- I don't know about that. * It's bad that the effectiveness of index-only scans is strongly influenced by the visibility map. And, autovacuum doesn't care about index-only scans (nor should it, I suppose). * The high watermark size of a table is much higher for an update-mostly workload. When bloat is localized to certain values in indexes, it's a lot worse. * Our behavior with many duplicates in secondary indexes is pretty bad in general, I suspect. I think we do badly at amortizing inserts into indexes from updates (we dirty more leaf pages than we really need to). I think we could do better at making LP_DEAD style IndexTuple recycling more effective. * Most obviously, autovacuum can create significant load at inconvenient times. Paying that cost in a piecemeal fashion has a certain appeal. For what it's worth, I am not planning to work on this. -- Peter Geoghegan -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
