Re: GIN fast insert

From: Teodor Sigaev <teodor(at)sigaev(dot)ru>
To: Simon Riggs <simon(at)2ndQuadrant(dot)com>
Cc: Robert Haas <robertmhaas(at)gmail(dot)com>, Pgsql Hackers <pgsql-hackers(at)postgresql(dot)org>
Subject: Re: GIN fast insert
Date: 2009-02-26 16:10:48
Message-ID: 49A6BF08.9070609@sigaev.ru
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: 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(at)sigaev(dot)ru
WWW: http://www.sigaev.ru/

In response to

Browse pgsql-hackers by date

  From Date Subject
Next Message Kevin Grittner 2009-02-26 16:30:04 Re: Synchronous replication & Hot standby patches
Previous Message Bruce Momjian 2009-02-26 16:07:45 Re: 8.4 release planning (was Re: [COMMITTERS] pgsql: Automatic view update rules)