From: | Simon Riggs <simon(at)2ndQuadrant(dot)com> |
---|---|
To: | Andres Freund <andres(at)2ndquadrant(dot)com> |
Cc: | Jeff Davis <pgsql(at)j-davis(dot)com>, pgsql-hackers(at)postgresql(dot)org |
Subject: | Re: Commits 8de72b and 5457a1 (COPY FREEZE) |
Date: | 2012-12-06 14:07:32 |
Message-ID: | CA+U5nMK+_Px8YZD7v49PLbzCUgx8Anw-ckoGghfB3H9XaqpSug@mail.gmail.com |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
On 6 December 2012 13:12, Andres Freund <andres(at)2ndquadrant(dot)com> wrote:
> Hi,
>
> On 2012-12-03 17:34:01 -0800, Jeff Davis wrote:
>> http://git.postgresql.org/gitweb/?p=postgresql.git;a=commitdiff;h=8de72b66a2edcf12c812de0a73bd50b6b7d81d62
>
> On the subject of that patch. I am not a big fan of only emitting a NOTICE if
> FREEZE wasn't properly used:
>
> + if (cstate->freeze && (hi_options & HEAP_INSERT_FROZEN) == 0)
> + ereport(NOTICE,
> + (errcode(ERRCODE_INVALID_PARAMETER_VALUE),
> + errmsg("FREEZE option specified but pre-conditions not met")));
> +
>
> Imo it should fail. Imagine adding FREEZE to the loading part of your
> application and not noticing the optimization broke because somebody
> else changed something in another part of the loading procedure.
>
> Not sure whether that discussed previously.
It was. Only Robert and I spoke about that.
Also imagine having to analyze your code in detail to reevaluate the
exact optimisation required each time. This way you get to add FREEZE
and have it work always, with feedback if its not optimized.
--
Simon Riggs http://www.2ndQuadrant.com/
PostgreSQL Development, 24x7 Support, Training & Services
From | Date | Subject | |
---|---|---|---|
Next Message | postgresql | 2012-12-06 14:10:29 | Re: Slow query: bitmap scan troubles |
Previous Message | Amit Kapila | 2012-12-06 13:39:59 | Re: Switching timeline over streaming replication |