| From: | "Pavan Deolasee" <pavan(dot)deolasee(at)gmail(dot)com> |
|---|---|
| To: | "Tom Lane" <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
| Cc: | "Florian G(dot) Pflug" <fgp(at)phlo(dot)org>, "Pavan Deolasee" <pavan(dot)deolasee(at)enterprisedb(dot)com>, "Simon Riggs" <simon(at)2ndquadrant(dot)com>, "Bruce Momjian" <bruce(at)momjian(dot)us>, PostgreSQL-development <pgsql-hackers(at)postgresql(dot)org> |
| Subject: | Re: CREATE INDEX and HOT - revised design |
| Date: | 2007-03-30 16:59:26 |
| Message-ID: | 2e78013d0703300959l2db69c60q9d7a74c02e8b52b9@mail.gmail.com |
| Views: | Raw Message | Whole Thread | Download mbox | Resend email |
| Thread: | |
| Lists: | pgsql-hackers |
On 3/30/07, Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> wrote:
>
>
>
> That might work, but it doesn't seem to address the core objection:
> there's no mechanism to cause the query to be replanned once the
> snapshot is new enough, because no relcache inval will happen. So
> most likely existing backends will keep using old plans that don't
> consider the index.
Can't we store the snapshot (or may be the transaction id) which was
used to plan the query in CachedPlanSource if and only if at least one
index was seen unusable ? In RevalidateCachedPlan() we then check if
the snapshot has changed and replan the query in that case.
That would make the index usable in the subsequent transactions
in the same session, though we may not be able to use the index
in the same transaction, even if its running in read-commited mode.
Would that be acceptable ?
Thanks,
Pavan
--
EnterpriseDB http://www.enterprisedb.com
| From | Date | Subject | |
|---|---|---|---|
| Next Message | Tom Lane | 2007-03-30 17:14:35 | Re: Autovacuum vs statement_timeout |
| Previous Message | Florian G. Pflug | 2007-03-30 16:54:14 | Re: CREATE INDEX and HOT - revised design |