From: | Jeffrey Tenny <jeffrey(dot)tenny(at)comcast(dot)net> |
---|---|
To: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
Cc: | "Jim C(dot) Nasby" <jnasby(at)pervasive(dot)com>, pgsql-performance(at)postgresql(dot)org |
Subject: | Re: performance question (something to do w/ parameterized |
Date: | 2006-05-08 20:33:46 |
Message-ID: | 445FAB2A.9050401@comcast.net |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers pgsql-performance |
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(dot)tenny(at)comcast(dot)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
>
From | Date | Subject | |
---|---|---|---|
Next Message | Tom Lane | 2006-05-08 20:49:58 | Re: performance question (something to do w/ parameterized |
Previous Message | Tom Lane | 2006-05-08 20:08:40 | Re: performance question (something to do w/ parameterized |
From | Date | Subject | |
---|---|---|---|
Next Message | Adam Palmblad | 2006-05-08 20:38:58 | |
Previous Message | Tom Lane | 2006-05-08 20:08:40 | Re: performance question (something to do w/ parameterized |