Re: GIN fast insert - Mailing list pgsql-hackers

From Robert Haas
Subject Re: GIN fast insert
Date
Msg-id 603c8f070902191943i6b1807e1ud53da4e1c09c7a5@mail.gmail.com
Whole thread Raw
In response to Re: GIN fast insert  (Teodor Sigaev <teodor@sigaev.ru>)
Responses Re: GIN fast insert
Re: GIN fast insert
List pgsql-hackers
On Thu, Feb 19, 2009 at 8:36 AM, Teodor Sigaev <teodor@sigaev.ru> wrote:
>> and I still think that's bogus.  It seems clear that this is going to
>> change much faster than plans are going to be invalidated, and if
>> autovacuum is doing its job, the pending list won't get long enough to
>> matter much anyway, right?  I don't think this patch should be
>> touching gincostestimate at all.
>
> Why not? For any estimation function it's possible to invent workload which
> will change cost (or optimal plan) much faster than plan's invalidation.
> Gincostestimate depends on statistic on table, not on real index's state,
> and plan's invalidation will occur after analyze run.

Hrm, hum, maybe you're right.

>> I am thinking that it is may not be necessary to remove the
>> gingettuple interface (as you did in v0.28.2).  Forcing a cleanup of
>> the pending list seems like a reasonable workaround.  We don't expect
>> this situation to come up frequently, so if the method we use to
>
> Agree
>
>> handle it is not terribly efficient, oh well.  The one thing that
>> concerns me is - what will happen in a hot standby environment, when
>> that patch is committed?  In that situation, I believe that we can't
>> call modify any heap or index pages, so...
>
> I don't see a problems here, because indexes in postgres don't depend on any
> transaction's ids or modes as heap depends. WAL-logger works without that
> knowledge too. May be I missed something here or don't understand.
>
> Although heap's pages could be changed by setting commit-status bits on
> tuple even in read-only transaction, but that changes are not WAL-logged.
> That is correct for index's page too.

It would be helpful if Heikki or Simon could jump in here, but my
understanding is that cleaning up the pending list is a read-write
operation.  I don't think we can do that on a hot standby server.

...Robert


pgsql-hackers by date:

Previous
From: Andrew Dunstan
Date:
Subject: Re: pg_restore new option -m
Next
From: Andrew Dunstan
Date:
Subject: Re: ORDER BY with EXCEPT?