Re: pgsql: Add pages deleted from pending list to FSM - Mailing list pgsql-committers

From Fujii Masao
Subject Re: pgsql: Add pages deleted from pending list to FSM
Date
Msg-id CAHGQGwEq+1YOazGiDRDs4Eu4wji7X697mUmmh5Yy2UfoacnL8g@mail.gmail.com
Whole thread Raw
In response to pgsql: Add pages deleted from pending list to FSM  (Teodor Sigaev <teodor@sigaev.ru>)
List pgsql-committers
On Mon, Sep 7, 2015 at 10:29 PM, Teodor Sigaev <teodor@sigaev.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


pgsql-committers by date:

Previous
From: Peter Eisentraut
Date:
Subject: pgsql: Order some new options on man pages more sensibly, minor improve
Next
From: Teodor Sigaev
Date:
Subject: pgsql: Add header forgotten in 213335c14529a8d5e2007ec0c256f4cf64d62d3b