> grovel through. The situation will only be rectified at the next vacuum,
> but if there's no deletes or updates on the table, just inserts,
> autovacuum won't happen until the next anti-wraparound vacuum.
There is not agreement here, see
http://archives.postgresql.org/message-id/2818.1216753264@sss.pgh.pa.us
> Yet another problem is that if so much work is offloaded to autovacuum,
> it can tie up autovacuum workers for a very long time. And the work can
> happen on an unfortunate time, when the system is busy, and affect other
> queries. There's no vacuum_delay_point()s in gininsertcleanup, so
> there's no way to throttle that work.
Will insert.
> I think we need a hard limit on the number of list pages, before we can
> consider accepting this patch. After the limit is full, the next
> inserter can flush the list, inserting the tuples in the list into the
> tree, or just fall back to regular, slow, inserts.
Hard limit is not very good decision
- If it will make a flush when limit is reached then sometimes insert or update
will take unacceptable amount of time. Small limit is not very helpful, large
will takes a lot of time. Although if we calculate limit using work_mem setting
then, may be, it will be useful. Bulk insert will collect all pending pages in
memory at once.
- Falling back to regular insert will take long time for update of whole table -
and that was one of reasons of that patch. Users forget to drop GIN index before
a global update and query runs forever.
--
Teodor Sigaev E-mail: teodor@sigaev.ru
WWW: http://www.sigaev.ru/
