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: http://www.postgresql.org/mailpref/pgsql-patches
