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

Peripheral Links

Header And Logo

PostgreSQL
| The world's most advanced open source database.

Site Navigation

Search for
  Advanced Search

Re: [PERFORM] temporary indexes


  • From: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
  • To: "Kevin Grittner" <Kevin(dot)Grittner(at)wicourts(dot)gov>
  • Cc: pgsql-hackers(at)postgresql(dot)org, pgsql-performance(at)postgresql(dot)org
  • Subject: Re: [PERFORM] temporary indexes
  • Date: Tue, 28 Feb 2006 11:52:11 -0500
  • Message-id: <15924(dot)1141145531(at)sss(dot)pgh(dot)pa(dot)us>

"Kevin Grittner" <Kevin(dot)Grittner(at)wicourts(dot)gov> writes:
> It struck me that it would be outstanding if the planner could
> recognize this sort of situation, and build a temporary index based on
> the snapshot of the data visible to the transaction.

I don't think that's an appropriate solution at all.  What it looks like
to me (assuming that explain's estimated row counts are reasonably
on-target) is that the time is all going into the EXISTS subplans.  The
real problem here is that we aren't doing anything to convert correlated
EXISTS subqueries into some form of join that's smarter than a raw
nestloop.

			regards, tom lane



Home | Main Index | Thread Index

Privacy Policy | PostgreSQL Archives hosted by Command Prompt, Inc. | Designed by tinysofa
Copyright © 1996 – 2008 PostgreSQL Global Development Group