Teodor Sigaev wrote:
>> How about having a constant sized "fastupdate" buffer, of say 100 rows  
>> or a fixed number of pages, and when that becomes full, the next  
>> inserter will have to pay the price of updating the index and flushing 
> I'm not sure that is acceptable because flushing pending list may take 
> several seconds in unpredictable moment.

Perhaps we could make the fixed-size buffer be of size X, and trigger
autovac on X/3 or some such, to give it enough slack so that it would be
very unlikely to be processed by user processes.

>> the buffer. To keep that overhead out of the main codepath, we could  
>> make autovacuum to flush the buffers periodically.
> Do you mean that GIN sends a "smoke signal" to the autovacuum launcher 
> process to ask about vacuum?

Something like that, yes.

Currently, autovac only uses pgstats as trigger for actions.  Maybe we
could use something else (say, a flag in shared memory?), or just stash
the info that the index needs to be processed in pgstats and have
autovac examine it.

Alvaro Herrera                                http://www.CommandPrompt.com/
The PostgreSQL Company - Command Prompt, Inc.

Sent via pgsql-patches mailing list (pgsql-patches@postgresql.org)
To make changes to your subscription:

Reply via email to