Re: temporary tables, indexes, and query plans
От | Tom Lane |
---|---|
Тема | Re: temporary tables, indexes, and query plans |
Дата | |
Msg-id | 25639.1289662872@sss.pgh.pa.us обсуждение исходный текст |
Ответ на | Re: temporary tables, indexes, and query plans (Jon Nelson <jnelson+pgsql@jamponi.net>) |
Ответы |
Re: temporary tables, indexes, and query plans
Re: temporary tables, indexes, and query plans |
Список | pgsql-performance |
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. You could avoid this effect either by creating the index before you do any updates on the table, or by not wrapping the entire process into a single transaction. regards, tom lane
В списке pgsql-performance по дате отправления: