Re: [PATCHES] GIN improvements

> 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/