On Wed, Nov 6, 2019 at 1:51 AM Tom Lane wrote:
> Amit Langote writes:
> > I have been thinking maybe add_child_rel_equivalences() doesn't need
> > to translate EC members that reference multiple appendrels, because
> > there top_parent_relids is always a singleton set, whereas em_relids
> > of su
Amit Langote writes:
> On Sun, Nov 3, 2019 at 4:43 AM Tom Lane wrote:
>> Also, I thought we should try to put more conditions on whether we
>> invoke add_child_join_rel_equivalences at all. In the attached I did
>> if ((enable_partitionwise_join || enable_partitionwise_aggregate) &&
>>
On Sun, Nov 3, 2019 at 4:43 AM Tom Lane wrote:
> Amit Langote writes:
> >> This would
> >> probably require refactoring things so that there are separate
> >> entry points to add child equivalences for base rels and join rels.
> >> But that seems cleaner anyway than what you've got here.
>
> > Se
Amit Langote writes:
>> This would
>> probably require refactoring things so that there are separate
>> entry points to add child equivalences for base rels and join rels.
>> But that seems cleaner anyway than what you've got here.
> Separate entry points sounds better, but only in HEAD?
I had a
Thanks for checking.
On Thu, Oct 31, 2019 at 1:09 AM Tom Lane wrote:
> Also, the existing logic around eclass_indexes is that it's only
> set for baserels and we know it is valid after we've finished
> EC merging. I don't much like modifying add_child_rel_equivalences
> to have some different op
On Thu, 31 Oct 2019 at 05:09, Tom Lane wrote:
> David --- much of the complexity here comes from the addition of
> the eclass_indexes infrastructure, so do you have any thoughts?
Hindsight makes me think I should have mentioned in the comment for
eclass_indexes that it's only used for simple rels
Amit Langote writes:
> Attached updated patches.
[ looks at that... ] I seriously, seriously dislike what you did
in build_join_rel, ie adding the new joinrel to the global data
structures before it's fully filled in. That's inevitably going
to bite us on the ass someday, and you couldn't even
Thanks for taking a look and sorry about the delay in replying.
On Fri, Oct 25, 2019 at 1:51 AM Tom Lane wrote:
> Amit Langote writes:
> > On Mon, Oct 14, 2019 at 11:54 PM Tom Lane wrote:
> >> In view of the proposed patches being dependent on some other
> >> 13-only changes, I wonder if we sho
Amit Langote writes:
> On Mon, Oct 14, 2019 at 11:54 PM Tom Lane wrote:
>> In view of the proposed patches being dependent on some other
>> 13-only changes, I wonder if we should fix v12 by reverting
>> d25ea0127. The potential planner performance loss for large
>> partition sets could be nasty,
Sorry about the late reply.
On Mon, Oct 14, 2019 at 11:54 PM Tom Lane wrote:
> Justin Pryzby writes:
> > On Sun, Oct 13, 2019 at 01:30:29PM -0500, Justin Pryzby wrote:
> >> BTW it probably should've been documented as an "Open Item" for v12.
>
> > https://commitfest.postgresql.org/25/2278/
> > I
On Sun, Oct 13, 2019 at 02:06:02PM -0400, Tom Lane wrote:
> Justin Pryzby writes:
> > On Fri, Oct 11, 2019 at 10:48:37AM -0400, Tom Lane wrote:
> >> Could you provide a self-contained test case please?
>
> > [ test case ]
>
> Oh, this is the same issue Amit described in
>
> https://www.postgre
On Sun, Oct 13, 2019 at 01:30:29PM -0500, Justin Pryzby wrote:
> BTW it probably should've been documented as an "Open Item" for v12.
https://commitfest.postgresql.org/25/2278/
I realized possibly people were thinking of that as a "feature" and not a
bugfix for backpatch (?)
But, my issue is a qu
Justin Pryzby writes:
> On Fri, Oct 11, 2019 at 10:48:37AM -0400, Tom Lane wrote:
>> Could you provide a self-contained test case please?
> [ test case ]
Oh, this is the same issue Amit described in
https://www.postgresql.org/message-id/flat/CA%2BHiwqG2WVUGmLJqtR0tPFhniO%3DH%3D9qQ%2BZ3L_ZC%2BY
Justin Pryzby writes:
> On Sun, Oct 13, 2019 at 01:30:29PM -0500, Justin Pryzby wrote:
>> BTW it probably should've been documented as an "Open Item" for v12.
> https://commitfest.postgresql.org/25/2278/
> I realized possibly people were thinking of that as a "feature" and not a
> bugfix for back
Justin Pryzby writes:
> On Fri, Oct 11, 2019 at 10:48:37AM -0400, Tom Lane wrote:
>> Could you provide a self-contained test case please?
> [ test case ]
Yup, fails for me too. Will look shortly.
regards, tom lane
On Fri, Oct 11, 2019 at 10:48:37AM -0400, Tom Lane wrote:
> Could you provide a self-contained test case please?
SET enable_partitionwise_aggregate = 'on';
SET enable_partitionwise_join = 'on';
SET max_parallel_workers_per_gather=0;
-- maybe not important but explain(settings) suggests I should in
Justin Pryzby writes:
> On Fri, Oct 11, 2019 at 10:48:37AM -0400, Tom Lane wrote:
>> Could you provide a self-contained test case please?
> I'm suspecting this; is it useful to test with this commit reverted ?
I wouldn't bother; we'd still need a test case to find out what the
problem is.
On Fri, Oct 11, 2019 at 10:48:37AM -0400, Tom Lane wrote:
> Justin Pryzby writes:
> > The view is actually a join of two relkind=p partitioned tables (which I
> > will acknowledge probably performs poorly).
>
> Could you provide a self-contained test case please?
Working on it. FWIW explain for
Justin Pryzby writes:
> I've reduced the failing query as much as possible to this:
> -- This is necessary to fail:
> SET enable_nestloop=off;
> SELECT * FROM
> (SELECT start_time, t1.site_id
> FROM pgw_kpi_view t1
> -- Apparently the where clause is necessary to fail...
>
I've reduced the failing query as much as possible to this:
-- This is necessary to fail:
SET enable_nestloop=off;
SELECT * FROM
(SELECT start_time, t1.site_id
FROM pgw_kpi_view t1
-- Apparently the where clause is necessary to fail...
WHERE (start_time>='2019-10-1
20 matches
Mail list logo
