Re: [NEWBIE] need help optimizing this query

From: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
To: Bill Moran <wmoran(at)potentialtech(dot)com>
Cc: Dexter Tad-y <dexterbt1(at)my(dot)smart(dot)com(dot)ph>, PostgreSQL <pgsql-general(at)postgresql(dot)org>
Subject: Re: [NEWBIE] need help optimizing this query
Date: 2004-03-10 16:35:23
Message-ID: 7476.1078936523@sss.pgh.pa.us
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-general

Bill Moran <wmoran(at)potentialtech(dot)com> writes:
> 3) Do you have indexes on a.xmax and b.transaction?

He can't index either (xmax is simply not indexable, and pg_locks is a view).

In a quick experiment I got reasonable-seeming join plans; the output of
pg_locks got hashed and then the system did a seqscan over the outer
table. It's not possible to do any better than that with the problem
as given. I assume the OP's problem is that the outer table is big and
he doesn't want to seqscan it. The only way I can see is to add an
additional filter condition that can be indexed, so that not all the
rows in the outer table have to be checked for xmax.

BTW, in 7.4 you get equivalently good plans with the more transparent

explain select * from foo where xmax not in
(select transaction from pg_locks where transaction is not null);

The EXPLAIN output looks different, but it's still effectively a hash
join.

regards, tom lane

In response to

Responses

Browse pgsql-general by date

  From Date Subject
Next Message Dexter Tad-y 2004-03-10 16:43:30 Re: [NEWBIE] need help optimizing this query
Previous Message scott.marlowe 2004-03-10 16:33:45 Re: load testing