| From: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
|---|---|
| To: | Jeffrey Tenny <jeffrey(dot)tenny(at)comcast(dot)net> |
| 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:49:58 |
| Message-ID: | 29684.1147121398@sss.pgh.pa.us |
| Views: | Raw Message | Whole Thread | Download mbox | Resend email |
| Thread: | |
| Lists: | pgsql-hackers pgsql-performance |
Jeffrey Tenny <jeffrey(dot)tenny(at)comcast(dot)net> writes:
> 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.
That's good, actually, seeing that the planner thinks they're close to
the same speed too. Now try "set enable_seqscan = off" to see if you
can force the multi-index-scan plan to be chosen, and see how that does.
regards, tom lane
| From | Date | Subject | |
|---|---|---|---|
| Next Message | Peter Eisentraut | 2006-05-08 21:28:13 | Re: Remove behaviour of postmaster -o |
| Previous Message | Jeffrey Tenny | 2006-05-08 20:33:46 | Re: performance question (something to do w/ parameterized |
| From | Date | Subject | |
|---|---|---|---|
| Next Message | Michael Stone | 2006-05-08 21:17:00 | Re: Memory and/or cache issues? |
| Previous Message | Adam Palmblad | 2006-05-08 20:38:58 |