Re: AW: AW: More Performance

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

In response to

Browse pgsql-hackers by date

  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...