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