On Thu, Feb 19, 2009 at 8:36 AM, Teodor Sigaev <teo...@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 -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
