Re: GIN fast insert - Mailing list pgsql-hackers

From Teodor Sigaev
Subject Re: GIN fast insert
Date
Msg-id 49A6BF08.9070609@sigaev.ru
Whole thread Raw
In response to Re: GIN fast insert  (Simon Riggs <simon@2ndQuadrant.com>)
List pgsql-hackers
> 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@sigaev.ru
  WWW: http://www.sigaev.ru/
 


pgsql-hackers by date:

Previous
From: Bruce Momjian
Date:
Subject: Re: 8.4 release planning (was Re: [COMMITTERS] pgsql: Automatic view update rules)
Next
From: "Kevin Grittner"
Date:
Subject: Re: Synchronous replication & Hot standby patches