From: Tom Lane <tgl@sss.pgh.pa.us>
To: Julien Rouhaud <rjuju123@gmail.com>
Cc: Andres Freund <andres@anarazel.de>
Cc: thibaut.madelaine@dalibo.com, Robert Haas <robertmhaas@gmail.com>
Cc: PostgreSQL mailing lists <pgsql-bugs@lists.postgresql.org>
Subject: Re: BUG #15669: Error with unnest in PG 11 (ERROR: 0A000)
Date: Thu, 07 Mar 2019 10:52:33 -0500
Message-ID: <15350.1551973953@sss.pgh.pa.us> (raw)
In-Reply-To: <CAOBaU_Z3BXYRABJNGAJvv=83zz1a-H9t7QAeXPTy+ejey2tpFg@mail.gmail.com>
References: <15669-02fb3296cca26203@postgresql.org>
<19353.1551800347@sss.pgh.pa.us>
<CAOBaU_YPJj95_9oskbobWxinOmfu3zJrNAnFD77yuzFTb6tmbA@mail.gmail.com>
<21482.1551806937@sss.pgh.pa.us>
<CAOBaU_ZE6+9YBL8htVC=hvV7Wv=Dd3i_Ze+NzW+ESuWpSsjoOw@mail.gmail.com>
<20477.1551819776@sss.pgh.pa.us>
<22437.1551824516@sss.pgh.pa.us>
<23541.1551826799@sss.pgh.pa.us>
<CAOBaU_bs7hbXxtvncLmfX34E4V8KQia6M8KSt4Lf_hapZKQtQQ@mail.gmail.com>
<2250.1551896629@sss.pgh.pa.us>
<1610.1551903135@sss.pgh.pa.us>
<CAOBaU_Z3BXYRABJNGAJvv=83zz1a-H9t7QAeXPTy+ejey2tpFg@mail.gmail.com>
Julien Rouhaud <rjuju123@gmail.com> writes:
> This all looks good to me. I'm wondering about this chunk though:
> + bool rel_is_partitioned = (rel->part_scheme && rel->part_rels);
> IIUC it' safe for now (according to f069c91a579), but should we use
> IS_PARTITIONED_REL macro instead? If yes, probably
> create_ordinary_grouping_paths() should be updated too.
Hmm, I was just copying the existing test in that function, but I agree
that it seems pretty random to not be using the macro.
Also, given that IS_PARTITIONED_REL is explicitly testing IS_DUMMY_REL,
it doesn't really seem like we need the hack about forcing nparts etc
to 0. I'd transferred that out of apply_scanjoin_target_to_paths into
set_dummy_rel_pathlist and mark_dummy_rel, but that doesn't make it any
less of an ugly kluge. In particular, that's not consistent with the
idea that an appendrel automatically becomes dummy if we generate a
zero-child path for it. So I'm now thinking we should drop that bit
and instead make sure that everyplace that's testing for partitioned-ness
is using this macro.
One more thing --- after sleeping in it, I'm questioning my earlier
feeling that apply_scanjoin_target_to_paths should flush existing paths
for partitioned rels. Maybe it was done like that with the idea of
letting paths with tlist computations done above the Append compete
with paths doing the tlist computations below? That would be a fine
idea if we had any costing factors that would produce a meaningful
choice between the two; but I'm afraid that what we're probably getting
right now is a quasi-random choice between paths whose costs differ
only by rounding errors.
regards, tom lane
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Reply to all the recipients using the --to and --cc options:
reply via email
To: pgsql-bugs@postgresql.org
Cc: tgl@sss.pgh.pa.us, rjuju123@gmail.com, andres@anarazel.de, robertmhaas@gmail.com, pgsql-bugs@lists.postgresql.org
Subject: Re: BUG #15669: Error with unnest in PG 11 (ERROR: 0A000)
In-Reply-To: <15350.1551973953@sss.pgh.pa.us>
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
This inbox is served by DDX for PostgreSQL; see mirroring instructions
for how to clone and mirror all data and code used for this inbox