| From: | Andrew Dunstan <andrew(at)dunslane(dot)net> |
|---|---|
| To: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
| Cc: | Gregory Stark <stark(at)enterprisedb(dot)com>, Nathan Boley <npboley(at)gmail(dot)com>, Jeff Davis <pgsql(at)j-davis(dot)com>, Zeugswetter Andreas OSB sIT <Andreas(dot)Zeugswetter(at)s-itsolutions(dot)at>, PostgreSQL-development <pgsql-hackers(at)postgresql(dot)org> |
| Subject: | Re: Proposal - improve eqsel estimates by including histogram bucket numdistinct statistics |
| Date: | 2008-06-11 01:41:47 |
| Message-ID: | 484F2D5B.7050508@dunslane.net |
| Views: | Raw Message | Whole Thread | Download mbox | Resend email |
| Thread: | |
| Lists: | pgsql-hackers |
Tom Lane wrote:
> This gets back to the discussions at PGCon about needing to have a more
> explicit representation of partitioning. Right now, for a
> many-partition table we spend huge amounts of time deriving the expected
> behavior from first principles, each time we make a plan. And even then
> we can only get it right for limited cases (eg, no parameterized
> queries). If the planner actually understood that a set of tables
> formed a partitioned set then it'd be a lot easier and faster to get the
> desired behavior, not only with respect to the rowcount estimates but
> the plan's structure.
>
>
>
Even if this doesn't solve every problem, it's surely worth doing for
those it will solve.
cheers
andrew
| From | Date | Subject | |
|---|---|---|---|
| Next Message | billy | 2008-06-11 03:21:31 | why copy tuple in the end of trigger when nothing changed in NEW OLD record variable |
| Previous Message | billy | 2008-06-11 01:30:45 | why copy tuple in the end of trigger when nothing changed in NEW OLD record variable |