Message-ID: <445FAB2A.9050401@comcast.net>
Date: Mon, 08 May 2006 16:33:46 -0400
From: Jeffrey Tenny <jeffrey.tenny@comcast.net>
User-Agent: Thunderbird 1.5 (X11/20051201)
MIME-Version: 1.0
To: Tom Lane <tgl@sss.pgh.pa.us>
CC: "Jim C. Nasby" <jnasby@pervasive.com>,
 pgsql-performance@postgresql.org
Subject: Re: performance question (something to do w/ parameterized
References: <445F7FF8.6070707@comcast.net>
	<20060508173812.GW99570@pervasive.com>
	<445F9F6B.9040200@comcast.net> <29345.1147118920@sss.pgh.pa.us>
In-Reply-To: <29345.1147118920@sss.pgh.pa.us>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit

The original set of indexes were:

Indexes:
     "x_c_idx" btree (c)
     "x_f_idx" btree (f)
     "testindex2" btree (f, c)

I dropped the multicolumn index 'testindex2',  and a new explain analyze 
looks like this:

  Sort  (cost=35730.71..35768.28 rows=1503 width=16) (actual 
time=962.555..964.467 rows=677 loops=1)
    Sort Key: f, c
    ->  Seq Scan on x  (cost=0.00..34937.60 rows=1503 width=16) (actual 
time=5.449..956.594 rows=677 loops=1)
          Filter: ((f = 1) OR (f = 2) OR (f = 3) ...


Turning on the server debugging again, I got roughly identical
query times with and without the two column index.
It appears to have ignored the other indexes completely.


Tom Lane wrote:
> Jeffrey Tenny <jeffrey.tenny@comcast.net> writes:
>> Well, since I don't know the exact parameter values, just substituting 
>> 1-650 for $1-$650, I get:
> 
>>   Index Scan using testindex2 on x  (cost=0.00..34964.52 rows=1503 
>> width=16) (actual time=0.201..968.252 rows=677 loops=1)
>>     Filter: ((f = 1) OR (f = 2) OR (f = 3) OR (f = 4) ...
> 
>> So index usage is presumably good on this one.
> 
> No, that's not a very nice plan at all --- the key thing to notice is
> it says Filter: not Index Cond:.  What you've actually got here is a
> full-index scan over testindex2 (I guess it's doing that to achieve the
> requested sort order), then computation of a 650-way boolean OR expression
> for each row of the table.  Ugh.
> 
> The other way of doing this would involve 650 separate index probes and
> then sorting the result.  Which would be pretty expensive too, but just
> counting on my fingers it seems like that ought to come out at less than
> the 35000 cost units for this plan.  The planner evidently is coming up
> with a different answer though.  You might try dropping testindex2
> (which I suppose is an index on (f,c)) so that it has only an index on
> f to play with, and see what plan it picks and what the estimated/actual
> costs are.
> 
> 			regards, tom lane
>