From: "Michael Rothschild" <michael(dot)r(at)corigin(dot)co(dot)il>
To: <pgsql-performance(at)postgresql(dot)org>
Subject:
Date: 2003-12-24 16:25:43
Message-ID: E8FD170A42773443AC1A5A438CC70F41052319@titan.corigin.co.il
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-performance

I consider using PostgreSQL for a project we have in our company and, to
get a better picture of the product, I started scanning its source code
and internal documentation.
Based on what I saw (and maybe I didn't see enough) it seems that the
optimizer will always decide to repeatedly scan the whole row set
returned by sub selects in the context of an IN clause sequentially, as
opposed to what I would expect it to do (which is to create some index
or hash structure to improve performance).
For example, if I have the following query:
Select * from a where x in (select y from b where z=7)
Then I would expect an index or hash structure to be created for b.y
when it is first scanned and brought into the cache but I couldn't see
it happening in the source.
As I said, I only inferred it from reading the source - not from actual
experiments - so I may be wrong.
1. Am I wrong?
2. If I'm right, is there any plan to change it (after all, in the
context of an IN clause, an index on the returned row set is all that is
needed - the row set itself does not seem to matter).

Thank you,

Michael Rothschild

Responses

  • Re: at 2003-12-25 02:47:28 from Christopher Kings-Lynne
  • Re: at 2003-12-25 16:28:54 from Tom Lane

Browse pgsql-performance by date

  From Date Subject
Next Message Christopher Kings-Lynne 2003-12-25 02:47:28 Re:
Previous Message Dave Cramer 2003-12-24 13:58:34 Re: is it possible to get the optimizer to use indexes