Re: AW: AW: More Performance - Mailing list pgsql-hackers

From Tom Lane
Subject Re: AW: AW: More Performance
Date
Msg-id 22624.959266255@sss.pgh.pa.us
Whole thread Raw
In response to AW: AW: More Performance  (Zeugswetter Andreas SB <ZeugswetterA@wien.spardat.at>)
List pgsql-hackers
Zeugswetter Andreas SB <ZeugswetterA@Wien.Spardat.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 likeselect * 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


pgsql-hackers by date:

Previous
From: "Michael A. Olson"
Date:
Subject: Re: AW: Berkeley DB...
Next
From: Tom Lane
Date:
Subject: Re: understanding Datum -> char * -> Datum conversions