Hello Tom! Thu, 21 Oct 2010 10:55:48 -0400, you wrote: > Gael Le Mignot <gael@xxxxxxxxxxxxxxxx> writes: >> The problem is when we index objects into the full-text search part of >> the database (which a DELETE and then an INSERT into a specific table), >> the INSERT sometimes take a long time (from 10s to 20s), but the same >> insert (and many other similar ones) are fast (below 0.2s). >> This slowness comes regularly, about every 200 objects indexed, >> regardless of the frequency of the inserts. > Hm. You didn't say which PG version you're using, but if it's >= 8.4, > I think this may be caused by GIN's habit of queuing index insertions > until it's accumulated a reasonable-size batch: > http://www.postgresql.org/docs/9.0/static/gin-implementation.html#GIN-FAST-UPDATE > While you can turn that off, I think that doing so will reduce the > index's search efficiency over time. It might be better to schedule > regular vacuums on the table so that the work is done by vacuum rather > than foreground queries. Thanks for your feedback. It seems to be related, at least, if I increase the work_mem variable, the slowness because bigger (up to 1 minute for a work_mem of 8mb) but much less frequent (around 0.05% instead of 0.5% of the requests for 8mb instead of 1mb). So a big work_mem and a regular vacuum would do the tick, I think. Does auto_vacuum triggers the gin index vacuuming too, or does it require a manual vacuum ? Regards, -- Gaël Le Mignot - gael@xxxxxxxxxxxxxxxx Pilot Systems - 9, rue Desargues - 75011 Paris Tel : +33 1 44 53 05 55 - www.pilotsystems.net Gérez vos contacts et vos newsletters : www.cockpit-mailing.com -- Sent via pgsql-performance mailing list (pgsql-performance@xxxxxxxxxxxxxx) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-performance
