From: | Pavan Deolasee <pavan(dot)deolasee(at)gmail(dot)com> |
---|---|
To: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
Cc: | pgsql-hackers <pgsql-hackers(at)postgresql(dot)org> |
Subject: | Re: Back-patch change in hashed DISTINCT estimation? |
Date: | 2013-08-21 03:44:59 |
Message-ID: | CABOikdP_c6j7NpQWaoxJJ4Zkq0uevxO0SZhpzn8CX=y+MAERJw@mail.gmail.com |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
On Wed, Aug 21, 2013 at 2:54 AM, Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)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 size leads it to choose a plan that is in fact better.)
> The risk of not back-patching is that the error could lead to
> out-of-memory failures because the hash aggregation uses more memory
> than the planner expected.
FWIW I recently investigated an out-of-memory issue in hash aggregation.
That case was because of use of a large temp table which was not manually
analysed and thus lead to a bad plan selection. But out of memory errors
are very confusing to the users and I have seen them unnecessarily
tinkering their memory settings to circumvent that issue. So +1 to fix the
bug in back branches, even though I understand there could be some
casualties on the border.
Thanks,
Pavan
--
Pavan Deolasee
http://www.linkedin.com/in/pavandeolasee
From | Date | Subject | |
---|---|---|---|
Next Message | Amit Kapila | 2013-08-21 04:40:32 | Re: ALTER SYSTEM SET command to change postgresql.conf parameters (RE: Proposal for Allow postgresql.conf values to be changed via SQL [review]) |
Previous Message | Bruce Momjian | 2013-08-21 01:59:40 | Re: ALTER SYSTEM SET command to change postgresql.conf parameters (RE: Proposal for Allow postgresql.conf values to be changed via SQL [review]) |