From: | Fujii Masao <masao(dot)fujii(at)gmail(dot)com> |
---|---|
To: | Teodor Sigaev <teodor(at)sigaev(dot)ru> |
Cc: | pgsql-committers <pgsql-committers(at)postgresql(dot)org> |
Subject: | Re: pgsql: Add pages deleted from pending list to FSM |
Date: | 2015-09-18 06:36:14 |
Message-ID: | CAHGQGwEq+1YOazGiDRDs4Eu4wji7X697mUmmh5Yy2UfoacnL8g@mail.gmail.com |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-committers pgsql-hackers |
On Mon, Sep 7, 2015 at 10:29 PM, Teodor Sigaev <teodor(at)sigaev(dot)ru> wrote:
> Add pages deleted from pending list to FSM
>
> Add pages deleted from GIN's pending list during cleanup to free space map
> immediately. Clean up process could be initiated by ordinary insert but adding
> page to FSM might occur only at vacuum. On some workload like never-vacuumed
> insert-only tables it could cause a huge bloat.
+ /*
+ * As pending list pages can have a high churn rate, it is
+ * desirable to recycle them immediately to the FreeSpace Map when
+ * ordinary backends clean the list.
+ */
+ if (fsm_vac && !vac_delay)
+ IndexFreeSpaceMapVacuum(index);
So autoanalyze still doesn't call IndexFreeSpaceMapVacuum().
That is, only backend can clean the list in INSERT-only workload.
I don't think that this is desirable. Because the backend will
periodically take a big performance penalty.
So I'm thinking that even autoanalyze should call IndexFreeSpaceMapVacuum()
to clean the list in a background, in order to avoid such spikes in
INSERT response time. Thought?
+ for (i = 0; i < data.ndeleted; i++)
+ RecordFreeIndexPage(index, freespace[i]);
ginvacuumcleanup calls RecordFreeIndexPage() twice for the same block.
One is in shiftList(), and another is in ginvacuumcleanup().
I'm just wondering if this affects the VACUUM performance especially
when the pending list size is set to very big.
Regards,
--
Fujii Masao
From | Date | Subject | |
---|---|---|---|
Next Message | Teodor Sigaev | 2015-09-18 11:32:52 | pgsql: Add header forgotten in 213335c14529a8d5e2007ec0c256f4cf64d62d3b |
Previous Message | Jan Wieck | 2015-09-18 02:01:45 | Re: [COMMITTERS] pgsql: Fix an O(N^2) problem in foreign key references. |
From | Date | Subject | |
---|---|---|---|
Next Message | Kyotaro HORIGUCHI | 2015-09-18 07:06:40 | Re: synchronous_commit = apply |
Previous Message | Jeff Janes | 2015-09-18 06:13:07 | Re: creating extension including dependencies |