| 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 23:06:01 |
| Message-ID: | 2398.1147129561@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 tried the seqscan disabling and got what sounds like the desired plan:
> Sort (cost=54900.62..54940.29 rows=1587 width=16) (actual time=20.208..22.138 rows=677 loops=1)
> Sort Key: f, c
> -> Index Scan using x_f_idx, x_f_idx, ...
> (cost=0.00..54056.96 rows=1587 width=16) (actual time=1.048..15.598 rows=677 loops=1)
> Index Cond: ((f = 1) OR (f = 2) OR (f = 3) ....
Hm, vs 35000 or so estimates for the slower plans. My recommendation
would be to decrease random_page_cost to 2 or so, instead of the brute
force disable-seqscans approach.
regards, tom lane
| From | Date | Subject | |
|---|---|---|---|
| Next Message | Tom Lane | 2006-05-08 23:13:52 | Re: BTree on-disk page ordering |
| Previous Message | Jim C. Nasby | 2006-05-08 22:50:26 | BTree on-disk page ordering |
| From | Date | Subject | |
|---|---|---|---|
| Next Message | Jeffrey Tenny | 2006-05-08 23:35:15 | Re: performance question (something to do w/ parameterized |
| Previous Message | Jeffrey Tenny | 2006-05-08 22:15:58 | Re: performance question (something to do w/ parameterized |