Re: CREATE INDEX and HOT - revised design
| От | Pavan Deolasee |
|---|---|
| Тема | Re: CREATE INDEX and HOT - revised design |
| Дата | |
| Msg-id | 2e78013d0703300959l2db69c60q9d7a74c02e8b52b9@mail.gmail.com обсуждение исходный текст |
| Ответ на | Re: CREATE INDEX and HOT - revised design (Tom Lane <tgl@sss.pgh.pa.us>) |
| Список | pgsql-hackers |
On 3/30/07, Tom Lane <tgl@sss.pgh.pa.us> wrote:
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
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
В списке pgsql-hackers по дате отправления: