From: | Etsuro Fujita <etsuro(dot)fujita(at)gmail(dot)com> |
---|---|
To: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
Cc: | Thomas Munro <thomas(dot)munro(at)gmail(dot)com>, Etsuro Fujita <efujita(at)postgresql(dot)org>, pgsql-committers <pgsql-committers(at)lists(dot)postgresql(dot)org> |
Subject: | Re: pgsql: Fix some issues with step generation in partition pruning. |
Date: | 2020-08-01 16:31:11 |
Message-ID: | CAPmGK15=c8Q-Ac3ogzZp_d6VsfRYSL2tD8zLwy_WYdrMXQhiCQ@mail.gmail.com |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-committers |
On Sat, Aug 1, 2020 at 11:13 PM Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> wrote:
> Thomas Munro <thomas(dot)munro(at)gmail(dot)com> writes:
> > Hi Fujita-san
> > I wonder if this build farm failure is related?
Thanks for letting me know!
> Sure looks that way, doesn't it? I'm just now working to reproduce
> on gaur's host and poke into it with a debugger. More news in an
> hour or two (it's slow :-().
Thanks for that!
I'm not sure this is related to that failure, but self-reviewing the
patch, one thing I noticed I missed is that get_steps_using_prefix()
assumes that clauses in the passed-in prefix list are sorted in an
ascending order of partkeyidx, but the caller (ie,
gen_prune_steps_from_opexps()) doesn't take that into account. I
might have broken something. I'm a bit tired today, so I'll look at
this more closely tomorrow.
Best regards,
Etsuro Fujita
From | Date | Subject | |
---|---|---|---|
Next Message | Tom Lane | 2020-08-01 18:16:30 | Re: pgsql: Fix some issues with step generation in partition pruning. |
Previous Message | Tom Lane | 2020-08-01 14:13:10 | Re: pgsql: Fix some issues with step generation in partition pruning. |