Re: temporary tables, indexes, and query plans
От | Robert Haas |
---|---|
Тема | Re: temporary tables, indexes, and query plans |
Дата | |
Msg-id | AANLkTi=bDh2TWJj-p8MGY=8yKx82YUULGXj1fQH_CMod@mail.gmail.com обсуждение исходный текст |
Ответ на | Re: temporary tables, indexes, and query plans (Tom Lane <tgl@sss.pgh.pa.us>) |
Ответы |
Re: temporary tables, indexes, and query plans
|
Список | pgsql-performance |
On Sat, Nov 13, 2010 at 10:41 AM, Tom Lane <tgl@sss.pgh.pa.us> wrote: > Jon Nelson <jnelson+pgsql@jamponi.net> writes: >> OK. This is a highly distilled example that shows the behavior. > >> BEGIN; >> CREATE TEMPORARY TABLE foo AS SELECT x AS A, chr(x % 75 + 32) AS b, >> ''::text AS c from generate_series(1,500) AS x; >> UPDATE foo SET c = 'foo' WHERE b = 'A' ; >> CREATE INDEX foo_b_idx on foo (b); >> [ and the rest of the transaction can't use that index ] > > OK, this is an artifact of the "HOT update" optimization. Before > creating the index, you did updates on the table that would have been > executed differently if the index had existed. When the index does get > created, its entries for those updates are incomplete, so the index > can't be used in transactions that could in principle see the unmodified > rows. Is the "in principle" here because there might be an open snapshot other than the one under which CREATE INDEX is running, like a cursor? -- Robert Haas EnterpriseDB: http://www.enterprisedb.com The Enterprise PostgreSQL Company
В списке pgsql-performance по дате отправления: