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/[EMAIL PROTECTED]
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: [EMAIL PROTECTED]
WWW: http://www.sigaev.ru/
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
