Robert Haas wrote: > Actually, I think that probably *is* worthwhile, specifically because > it might let us avoid multiple index scans in cases where we currently > require them. Right now, our default maintenance_work_mem value is > 64MB, which is enough to hold a little over ten million tuples. It's > also large enough to hold a bitmap for a 14GB table. So right now if > you deleted, say, 100 tuples per page you would end up with an index > vacuum cycles for every ~100,000 pages = 800MB, whereas switching to > the bitmap representation for such cases would require only one index > vacuum cycle for every 14GB, more than an order of magnitude > improvement!
Yeah, this sounds worthwhile. If we switch to the more compact in-memory representation close to the point where we figure the TID array is not going to fit in m_w_m, then we're saving some number of additional index scans, and I'm pretty sure that the time to transform from array to bitmap is going to be more than paid back by the I/O savings. One thing not quite clear to me is how do we create the bitmap representation starting from the array representation in midflight without using twice as much memory transiently. Are we going to write the array to a temp file, free the array memory, then fill the bitmap by reading the array from disk? -- Álvaro Herrera https://www.2ndQuadrant.com/ PostgreSQL Development, 24x7 Support, Remote DBA, 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
