| From: | "Nathan Boley" <npboley(at)gmail(dot)com> |
|---|---|
| To: | "Tom Lane" <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
| Cc: | "Jeff Davis" <pgsql(at)j-davis(dot)com>, "Zeugswetter Andreas OSB sIT" <Andreas(dot)Zeugswetter(at)s-itsolutions(dot)at>, "Gregory Stark" <stark(at)enterprisedb(dot)com>, PostgreSQL-development <pgsql-hackers(at)postgresql(dot)org> |
| Subject: | Re: Proposal - improve eqsel estimates by including histogram bucket numdistinct statistics |
| Date: | 2008-06-10 19:16:11 |
| Message-ID: | 6fa3b6e20806101216n5dd675eak954f54701a6ce268@mail.gmail.com |
| Views: | Raw Message | Whole Thread | Download mbox | Resend email |
| Thread: | |
| Lists: | pgsql-hackers |
>> If we query on values that aren't in the table, the planner will
>> always overestimate the expected number of returned rows because it (
>> implicitly ) assumes that every query will return at least 1 record.
>
> That's intentional and should not be changed.
Why? What if ( somehow ) we knew that there was a 90% chance that
query would return an empty result set on a big table with 20 non-mcv
distinct values. Currently the planner would always choose a seq scan,
where an index scan might be better. Better yet, couldn't that be
optimized to *if record exists, execute seq scan*. That being said, I
think queries are generally searching for values that exist in the
table.
> I can't see the value of allowing fractional-row estimates anyway.
Neither can I, but I could probably think of cases where knowing the
SD of the result set could result in better plans.
-Nathan
| From | Date | Subject | |
|---|---|---|---|
| Next Message | Tom Lane | 2008-06-10 20:33:17 | Re: Proposal - improve eqsel estimates by including histogram bucket numdistinct statistics |
| Previous Message | Tom Lane | 2008-06-10 18:54:11 | Re: Proposal - improve eqsel estimates by including histogram bucket numdistinct statistics |