On 10/18/2016 11:28 AM, Alvaro Herrera wrote:
Vacuuming presents an additional challenge: in order to remove index items from an indirect index, it's critical to scan the PK index first and collect the PK values that are being removed. Then scan the indirect index and remove any items that match the PK items removed. This is a bit problematic because of the additional memory needed to store the array of PK values. I haven't implemented this yet.
As a whole I think the idea is interesting but the above scares me. Are we trading initial performance gains for performance degradation through maintenance? Since autovacuum is an indeterminate launch we could have a situation where even a medium level updated laden table becomes a source of contentions for IO and memory resources. I don't know that we would see issues on modern bare metal but considering our implementation space is places like RDS and GCE now, this is a serious consideration.
Sincerely, JD -- Command Prompt, Inc. http://the.postgres.company/ +1-503-667-4564 PostgreSQL Centered full stack support, consulting and development. Everyone appreciates your honesty, until you are honest with them. -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
