| From: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
|---|---|
| To: | Jaime Casanova <systemguards(at)gmail(dot)com> |
| Cc: | Josh Berkus <josh(at)agliodbs(dot)com>, performance pgsql <pgsql-performance(at)postgresql(dot)org> |
| Subject: | Re: estimated rows vs. actual rows |
| Date: | 2005-02-14 03:38:01 |
| Message-ID: | 19674.1108352281@sss.pgh.pa.us |
| Views: | Raw Message | Whole Thread | Download mbox | Resend email |
| Thread: | |
| Lists: | pgsql-performance |
Jaime Casanova <systemguards(at)gmail(dot)com> writes:
> But, IMHO, if the table has 143902 and it thinks will retrieve 2610
> (almost 1.81% of the total). it won't be faster with an index?
That's almost one row in fifty. We don't know how wide the table is,
but it's certainly possible that there are order-of-a-hundred rows
on each page; in which case the indexscan is likely to hit every page.
Twice. Not in sequence. Only if the selected rows are pretty well
clustered in a small part of the table is this going to be a win
over a seqscan.
regards, tom lane
| From | Date | Subject | |
|---|---|---|---|
| Next Message | Mark Kirkwood | 2005-02-14 03:45:58 | Re: estimated rows vs. actual rows |
| Previous Message | Jaime Casanova | 2005-02-14 03:18:52 | Re: estimated rows vs. actual rows |