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: teo...@sigaev.ru
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
