Re: FSM versus GIN pending list bloat - Mailing list pgsql-hackers

From Fujii Masao
Subject Re: FSM versus GIN pending list bloat
Date
Msg-id CAHGQGwFdMtVUT_UXkj2B4mTpgf8pwpNc1S_+BdDzyehTuyRhwA@mail.gmail.com
Whole thread Raw
In response to Re: FSM versus GIN pending list bloat  (Simon Riggs <simon@2ndQuadrant.com>)
List pgsql-hackers
On Wed, Aug 5, 2015 at 5:50 AM, Simon Riggs <simon@2ndquadrant.com> wrote:
> On 4 August 2015 at 21:04, Jeff Janes <jeff.janes@gmail.com> wrote:
>
>>>
>>> Couple of questions here...
>>>
>>> * the docs say "it's desirable to have pending-list cleanup occur in the
>>> background", but there is no way to invoke that, except via VACUUM. I think
>>> we need a separate function to be able to call this as a background action.
>>> If we had that, we wouldn't need much else, would we?
>>
>>
>> I thought maybe the new bgworker framework would be a way to have a
>> backend signal a bgworker to do the cleanup when it notices the pending list
>> is getting large.  But that wouldn't directly fix this issue, because the
>> bgworker still wouldn't recycle that space (without further changes), only
>> vacuum workers do that currently.
>>
>> But I don't think this could be implemented as an extension, because the
>> signalling code has to be in core, so (not having studied the matter at all)
>> I don't know if it is good fit for bgworker.
>
>
> We need to expose 2 functions:
>
> 1. a function to perform the recycling directly (BRIN has an equivalent
> function)
>
> 2. a function to see how big the pending list is for a particular index,
> i.e. do we need to run function 1?

Probably you can use pgstatginindex() that pgstattuple contrib module provides
for this case.

Regards,

-- 
Fujii Masao



pgsql-hackers by date:

Previous
From: Pavan Deolasee
Date:
Subject: Re: Horizontal scalability/sharding
Next
From: Amit Kapila
Date:
Subject: Re: Horizontal scalability/sharding