Skip site navigation (1) Skip section navigation (2)

Re: temporary tables, indexes, and query plans

From: Robert Haas <robertmhaas(at)gmail(dot)com>
To: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
Cc: Jon Nelson <jnelson+pgsql(at)jamponi(dot)net>, pgsql-performance(at)postgresql(dot)org
Subject: Re: temporary tables, indexes, and query plans
Date: 2010-11-14 00:46:05
Message-ID: AANLkTi=bDh2TWJj-p8MGY=8yKx82YUULGXj1fQH_CMod@mail.gmail.com (view raw or flat)
Thread:
Lists: pgsql-performance
On Sat, Nov 13, 2010 at 10:41 AM, Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> wrote:
> Jon Nelson <jnelson+pgsql(at)jamponi(dot)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

In response to

Responses

pgsql-performance by date

Next:From: Tom LaneDate: 2010-11-14 00:54:06
Subject: Re: temporary tables, indexes, and query plans
Previous:From: Robert HaasDate: 2010-11-14 00:20:22
Subject: Re: anti-join chosen even when slower than old plan

Privacy Policy | About PostgreSQL
Copyright © 1996-2014 The PostgreSQL Global Development Group