From: | Marti Raudsepp <marti(at)juffo(dot)org> |
---|---|
To: | Alexander Korotkov <aekorotkov(at)gmail(dot)com> |
Cc: | 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-01-28 03:41:32 |
Message-ID: | CABRT9RC-erXdcuoL7=0uvWGp+jq1nuTWDpGS8QBLK8JrOHw8=A@mail.gmail.com |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
On Mon, Jan 27, 2014 at 9:26 PM, Alexander Korotkov
<aekorotkov(at)gmail(dot)com> wrote:
> For now, I have attempt to fix extra columns in mergejoin problem. It would
> be nice if you test it.
Yes, it solves the test cases I was trying with, thanks.
> 1) With enable_partialsort = off all mergejoin logic should behave as
> without partial sort patch.
> 2) With partial sort patch get_cheapest_fractional_path_for_pathkeys
> function is much more expensive to execute. With enable_partialsort = off it
> should be as cheap as without partial sort patch.
When it comes to planning time, I really don't think you should
bother. The planner enable_* settings are meant for troubleshooting,
debugging and learning about the planner. You should not expect people
to disable them in a production setting. It's not worth complicating
the code for that rare case.
This is stated in the documentation
(http://www.postgresql.org/docs/current/static/runtime-config-query.html)
and repeatedly on the mailing lists.
But some benchmarks of planning performance are certainly warranted.
Regards,
Marti
From | Date | Subject | |
---|---|---|---|
Next Message | Andrew Dunstan | 2014-01-28 03:43:01 | Re: jsonb and nested hstore |
Previous Message | Robert Haas | 2014-01-28 03:39:25 | Re: Performance Improvement by reducing WAL for Update Operation |