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.