Re: GIN fast insert

> Teodor, can you confirm
> * we WAL log the insert into the pending list
> * we WAL log the move from the pending list to the main index
Yes, I can and I confirm

> * that we maintain the pending list correctly during redo so that it can
> be accessed by index scans
Not sure about correct locking in ginxlog.c - but it should fixable rather easy.

> The main thing with Hot Standby is that we can't do any writes. So a
> pending list cannot change solely because of a gingettuple call on the
> *standby*. But that's easy to disable. If all the inserts happened on
Right. And suggest to increase work_mem.

> the primary node and all the reads happened on the standby, then pending
> list would never be cleaned up if the cleanup is triggered only by read.
> I would suggest that we trigger cleanup by read at threshold size X and
> trigger cleanup by insert at threshold size 5X. That avoids the strange
threshold is not helpful here because for gininsert and gingettuple it depends
on work_mem setting which could be very different on slave(s) and master. Next,
it's possible that master never executes read-only queries (i.e. gingettuple
will not be called) by application's design.

This is a strong objection for invocation of cleanup from gingettuple. So, I'm
inclined to Tom's idea about removing gingettuple interface although GIN with
fastupdate=off doesn't affect discussed problem .

> I found many parts of the patch and docs quite confusing because of the
> way things are named. For me, this is a deferred or delayed insert
> technique to allow batching. I would prefer if everything used one
> description, rather than "fast", "pending", "delayed" etc.
Terminology was taken from inverted index technique.

--
Teodor Sigaev E-mail: teodor(at)sigaev(dot)ru
WWW: http://www.sigaev.ru/