Re: pgsql: Add pages deleted from pending list to FSM

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

In response to

Responses

Browse pgsql-committers by date

  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.

Browse pgsql-hackers by date

  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