| From: | Robert Haas <robertmhaas(at)gmail(dot)com> |
|---|---|
| To: | Marti Raudsepp <marti(at)juffo(dot)org> |
| Cc: | Alexander Korotkov <aekorotkov(at)gmail(dot)com>, Andreas Karlsson <andreas(at)proxel(dot)se>, David Rowley <dgrowleyml(at)gmail(dot)com>, pgsql-hackers <pgsql-hackers(at)postgresql(dot)org>, Andres Freund <andres(at)2ndquadrant(dot)com>, Martijn van Oosterhout <kleptog(at)svana(dot)org> |
| Subject: | Re: PoC: Partial sort |
| Date: | 2014-02-06 03:31:47 |
| Message-ID: | CA+TgmoYMPcbSmdZr-khRSPOH3H3H_SDd=9LjOOLk2Hvmo3OvZg@mail.gmail.com |
| Views: | Raw Message | Whole Thread | Download mbox | Resend email |
| Thread: | |
| Lists: | pgsql-hackers |
On Wed, Feb 5, 2014 at 6:58 PM, Marti Raudsepp <marti(at)juffo(dot)org> wrote:
> I ran some synthetic benchmarks with single-column inner joins between 5
> tables, with indexes on both joined columns, using only EXPLAIN (so
> measuring planning time, not execution) in 9 scenarios to excercise
> different code paths. According to these measurements, the overhead ranges
> between 1.0 and 4.5% depending on the scenario.
Hmm, sounds a little steep. Why is it so expensive? I'm probably
missing something here, because I would have thought that planner
support for partial sorts would consist mostly of considering the same
sorts we consider today, but with the costs reduced by the batching.
Changing the cost estimation that way can't be that much more
expensive than what we're already doing, so the overhead should be
minimal. What the patch is actually doing seems to be something quite
a bit more invasive than that, but I'm not sure what it is exactly, or
why.
--
Robert Haas
EnterpriseDB: http://www.enterprisedb.com
The Enterprise PostgreSQL Company
| From | Date | Subject | |
|---|---|---|---|
| Next Message | Robert Haas | 2014-02-06 03:37:20 | Re: Performance Improvement by reducing WAL for Update Operation |
| Previous Message | Robert Haas | 2014-02-06 02:57:58 | Re: Add CREATE support to event triggers |