From: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
---|---|
To: | Zeugswetter Andreas SB <ZeugswetterA(at)Wien(dot)Spardat(dot)at> |
Cc: | "'pgsql-hackers(at)postgresql(dot)org'" <pgsql-hackers(at)postgresql(dot)org> |
Subject: | Re: AW: AW: More Performance |
Date: | 2000-05-25 14:50:55 |
Message-ID: | 22624.959266255@sss.pgh.pa.us |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
Zeugswetter Andreas SB <ZeugswetterA(at)Wien(dot)Spardat(dot)at> writes:
> But, it probably shows a problem with the chosen metric for
> selectivity itself. Imho the chances are better, that an =
> restriction will return an equal amount of rows while the table grows
> than that it will return a percentage of total table size.
Unfortunately you are allowing your thinking to be driven by a single
example. Consider queries like
select * from employees where dept = 'accounting';
It's perfectly possible that the column being tested with '=' has only
a small number of distinct values, in which case the number of retrieved
rows probably *is* proportional to the table size.
I am not willing to change the planner so that it "guarantees" to choose
an indexscan no matter what, because then it would be broken for cases
like this. We have to look at the statistics we have, inadequate though
they are.
regards, tom lane
From | Date | Subject | |
---|---|---|---|
Next Message | Tom Lane | 2000-05-25 14:55:05 | Re: understanding Datum -> char * -> Datum conversions |
Previous Message | Michael A. Olson | 2000-05-25 14:41:08 | Re: AW: Berkeley DB... |