On Mon, Mar 18, 2019 at 8:09 AM Noah Misch wrote:
> On Tue, Oct 02, 2018 at 10:53:40AM -0400, Tom Lane wrote:
> > Noah Misch writes:
> > > On Mon, Oct 01, 2018 at 09:32:10PM -0400, Tom Lane wrote:
> > >> FWIW, my problem with this patch is that I remain unconvinced of the
> basic
> > >> correctn
On Tue, Oct 02, 2018 at 10:53:40AM -0400, Tom Lane wrote:
> Noah Misch writes:
> > On Mon, Oct 01, 2018 at 09:32:10PM -0400, Tom Lane wrote:
> >> FWIW, my problem with this patch is that I remain unconvinced of the basic
> >> correctness of the transform (specifically the unique-ification approach
Noah Misch writes:
> On Mon, Oct 01, 2018 at 09:32:10PM -0400, Tom Lane wrote:
>> FWIW, my problem with this patch is that I remain unconvinced of the basic
>> correctness of the transform (specifically the unique-ification approach).
>> Noah's points would be important to address if we were movin
On Mon, Oct 01, 2018 at 09:32:10PM -0400, Tom Lane wrote:
> Michael Paquier writes:
> > On Mon, Sep 03, 2018 at 06:59:10PM -0700, Noah Misch wrote:
> >> If you're going to keep this highly-simplified estimate, please expand the
> >> comment to say why it doesn't matter or what makes it hard to do
Michael Paquier writes:
> On Mon, Sep 03, 2018 at 06:59:10PM -0700, Noah Misch wrote:
>> If you're going to keep this highly-simplified estimate, please expand the
>> comment to say why it doesn't matter or what makes it hard to do better. The
>> non-planunionor.c path for the same query computes
On Mon, Sep 03, 2018 at 06:59:10PM -0700, Noah Misch wrote:
> If you're going to keep this highly-simplified estimate, please expand the
> comment to say why it doesn't matter or what makes it hard to do better. The
> non-planunionor.c path for the same query computes its own estimate of the
> sam
On Sun, Feb 12, 2017 at 09:32:36AM -0800, Tom Lane wrote:
> It's not so much poor choices as the cost of the optimization attempt ---
> if there's a K-relation OR clause, this will increase the cost of planning
> by a factor approaching K+1, whether or not you get a better plan out of
> it. I ran
On Thu, Aug 23, 2018 at 5:20 PM, Peter Geoghegan wrote:
> This patch adds an enhancement that is an example of a broader class
> of optimizer enhancement primarily aimed at making star-schema queries
> have more efficient plans, by arranging to use several independent
> nested loop joins based on
On Thu, Aug 23, 2018 at 11:10 AM, Tom Lane wrote:
> Rebased up to HEAD, per cfbot nagging. Still no substantive change from
> v2.
I happened to have the opportunity to talk to Tom about this patch in
person. I expressed some very general concerns that are worth
repeating publicly.
This patch ad
I wrote:
> [ join-or-to-union-4.patch ]
Rebased up to HEAD, per cfbot nagging. Still no substantive change from
v2.
regards, tom lane
diff --git a/src/backend/nodes/outfuncs.c b/src/backend/nodes/outfuncs.c
index 6269f47..8935503 100644
*** a/src/backend/nodes/outfuncs.c
On 30 March 2018 at 15:05, Andres Freund wrote:
>> + * To allow join removal to happen, we can't reference the CTID column
>> + * of an otherwise-removable relation.
>
> A brief hint why wouldn't hurt.
Maybe something like:
/*
* Join removal is only ever possible when no columns of the
to-be-re
On 3 February 2018 at 03:26, Tom Lane wrote:
> Tomas Vondra writes:
>> ISTM this patch got somewhat stuck as we're not quite sure the
>> transformation is correct in all cases. Is my impression correct?
>
> Yeah, that's the core issue.
>
>> If yes, how to we convince ourselves? Would some sort of
Hi,
I've only skimmed the thread, looking at the patch on its own.
On 2018-01-04 17:50:48 -0500, Tom Lane wrote:
> diff --git a/src/backend/optimizer/plan/plaindex ...dd11e72 .
> --- a/src/backend/optimizer/plan/planunionor.c
> +++ b/src/backend/optimizer/plan/planunionor.c
> @@ -0,0 +1,667 @@
>
On Fri, Feb 2, 2018 at 4:53 PM, Tom Lane wrote:
> Tomas Vondra writes:
>> BTW wouldn't it be possible to derive "traditional" proof in relational
>> algebra, similarly to other transforms?
>
> Perhaps. The patch depends on CTID, but you could probably model that
> as a primary key in a proof.
I
Tomas Vondra writes:
> BTW wouldn't it be possible to derive "traditional" proof in relational
> algebra, similarly to other transforms?
Perhaps. The patch depends on CTID, but you could probably model that
as a primary key in a proof.
regards, tom lane
On 02/02/2018 03:26 PM, Tom Lane wrote:
> Tomas Vondra writes:
>> ISTM this patch got somewhat stuck as we're not quite sure the
>> transformation is correct in all cases. Is my impression correct?
>
> Yeah, that's the core issue.
>
>> If yes, how to we convince ourselves? Would some sort of a
Tomas Vondra writes:
> ISTM this patch got somewhat stuck as we're not quite sure the
> transformation is correct in all cases. Is my impression correct?
Yeah, that's the core issue.
> If yes, how to we convince ourselves? Would some sort of automated testing
> (generating data and queries) help
On 01/04/2018 11:50 PM, Tom Lane wrote:
> I wrote:
>> Jim Nasby writes:
>>> I've verified that the patch still applies and make check-world is clean.
>
>> Not any more :-(. Here's a v3 rebased over HEAD. No substantive
>> change from v2.
>
> Again rebased up to HEAD; still no substantive chang
I wrote:
> Jim Nasby writes:
>> I've verified that the patch still applies and make check-world is clean.
> Not any more :-(. Here's a v3 rebased over HEAD. No substantive
> change from v2.
Again rebased up to HEAD; still no substantive changes.
regards, tom lane
diff
On Tue, Sep 12, 2017 at 9:48 PM, Tom Lane wrote:
> Jim Nasby writes:
>> I've verified that the patch still applies and make check-world is clean.
>
> Not any more :-(. Here's a v3 rebased over HEAD. No substantive
> change from v2.
Patch applies and compiles, and it got no reviews. Moved to CF
20 matches
Mail list logo
