On 2013-08-20 17:24:18 -0400, Tom Lane wrote:
In a thread over in pgsql-performance, Tomas Vondra pointed out that
choose_hashed_distinct was sometimes making different choices than
choose_hashed_grouping, so that queries like these:
select distinct x from ... ;
select x from
* Andres Freund (and...@2ndquadrant.com) wrote:
On 2013-08-20 17:24:18 -0400, Tom Lane wrote:
In a thread over in pgsql-performance, Tomas Vondra pointed out that
choose_hashed_distinct was sometimes making different choices than
choose_hashed_grouping, so that queries like these:
Stephen Frost sfr...@snowman.net wrote:
Yeah, I've been thinking about this a bit also and agree that 9.3
is fine but not farther back.
+1 to 9.3 but no farther back.
I would be in favor of going farther back if there were not fairly
obvious workarounds for the OOM problems that lack of
On Wed, Aug 21, 2013 at 4:05 AM, Andres Freund and...@2ndquadrant.com wrote:
On 2013-08-20 17:24:18 -0400, Tom Lane wrote:
In a thread over in pgsql-performance, Tomas Vondra pointed out that
choose_hashed_distinct was sometimes making different choices than
choose_hashed_grouping, so that
In a thread over in pgsql-performance, Tomas Vondra pointed out that
choose_hashed_distinct was sometimes making different choices than
choose_hashed_grouping, so that queries like these:
select distinct x from ... ;
select x from ... group by 1;
might get different plans even
On Wed, Aug 21, 2013 at 2:54 AM, Tom Lane t...@sss.pgh.pa.us wrote:
What I'm wondering is whether to back-patch this or leave well enough
alone. The risk of back-patching is that it might destabilize plan
choices that people like. (In Tomas' original example, the underestimate
of the table
