Re: [SQL] qurey plan and indices

From: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
To: Patrick Giagnocavo <a222(at)redrose(dot)net>
Cc: pgsql-sql(at)postgreSQL(dot)org
Subject: Re: [SQL] qurey plan and indices
Date: 1999-08-05 14:39:26
Message-ID: 4175.933863966@sss.pgh.pa.us
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-sql

Patrick Giagnocavo <a222(at)redrose(dot)net> writes:
> MESZAROS Attila wrote:
>>
>> I've experienced a brutal speedup (order of 2) separateing the following
>> subquery and making it manually:
>>
>> explain select name,description
>> from descriptions
>> where in (select name
>> from descriptions
>> where description like '%Bankverbindung%');

> Correct me if I am wrong, however if using
> LIKE '%something%'
> (which means, the field contains 'something' somewhere in the field)
> there is never a chance to use the index you have created - a
> sequential table scan MUST be made, thus you have to read all 3575
> rows to return the set.

Yes. The inner query must happen by sequential scan. But the outer
query can use an index if it is in the form
... where (name = 'a') or (name = 'b') or (name = 'c');
which is what "where name in ('a','b','c')" gets translated to.

However, the *real* problem here is that the inner query is treated
as a subplan, which means it is re-evaluated for each tuple scanned
by the outer query. This is not very bright; the system ought to
notice that the inner query does not depend on the state of the
outer query, and do it only once. There is already a notion of
InitPlan vs. SubPlan. I'm not sure why this case is being classified
as a SubPlan, but it sure looks like it ought to be done as an
InitPlan...

regards, tom lane

Responses

Browse pgsql-sql by date

  From Date Subject
Next Message MESZAROS Attila 1999-08-05 14:51:21 Re: [SQL] qurey plan and indices
Previous Message Tom Lane 1999-08-05 14:26:16 Re: [SQL] primary key view failure