From: | "Joshua D(dot) Drake" <jd(at)commandprompt(dot)com> |
---|---|
To: | Alvaro Herrera <alvherre(at)2ndquadrant(dot)com>, Pg Hackers <pgsql-hackers(at)postgresql(dot)org> |
Subject: | Re: Indirect indexes |
Date: | 2016-10-18 19:41:16 |
Message-ID: | 2f5e6c38-4103-3def-2d6a-24d6509ed34e@commandprompt.com |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
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.
From | Date | Subject | |
---|---|---|---|
Next Message | Robert Haas | 2016-10-18 20:00:37 | Re: "Some tests to cover hash_index" |
Previous Message | Tom Lane | 2016-10-18 18:47:53 | Re: [ADMIN] 9.5 new setting "cluster name" and logging |