On 8/29/18 1:38 PM, Robert Haas wrote:
> On Mon, Aug 27, 2018 at 6:05 PM, Jonathan S. Katz
> wrote:
>> On behalf of the RMT, I just want to make sure this keeps moving along.
>> It sounds like the next step is for Robert to verify that [3] is the
>> expected
>> behavior and then David can decide
On Thu, 16 Aug 2018 at 11:38, Alvaro Herrera wrote:
>
> On 2018-Jul-23, Jaime Casanova wrote:
>
>
> > I was trying sqlsmith on REL_11_STABLE (commit
> > 1b957e59b92dc44c14708762f882d7910463a9ac) with a database i have at
> > hand, and got an assertion failure.
> > It seems to happen during
On Fri, Aug 17, 2018 at 2:58 AM, David Rowley
wrote:
>> I'm baffled as to why looking through Gather to find
>> Append/MergeAppend subpaths would ever be a sane thing to do.
>
> Can you explain why it's less sane than what the current code is
> doing? Below a Gather there will be partial paths,
On Mon, Aug 27, 2018 at 6:05 PM, Jonathan S. Katz wrote:
> On behalf of the RMT, I just want to make sure this keeps moving along.
> It sounds like the next step is for Robert to verify that [3] is the
> expected
> behavior and then David can decide what to do from there.
Yes, that's the
> On Aug 17, 2018, at 2:49 AM, David Rowley
> wrote:
>
> On 17 August 2018 at 06:52, Robert Haas wrote:
>> I don't know whether there's actually a defect here any more. I was
>> trying to dispel some perceived confusion on the part of David and Tom
>> about what this code was trying to
On 14 August 2018 at 09:23, Robert Haas wrote:
> On Sat, Aug 11, 2018 at 9:16 AM, David Rowley
> wrote:
>> I started debugging this to see where things go wrong. I discovered
>> that add_paths_to_append_rel() is called yet again from
>> apply_scanjoin_target_to_paths() and this is where it's all
On 17 August 2018 at 06:52, Robert Haas wrote:
> I don't know whether there's actually a defect here any more. I was
> trying to dispel some perceived confusion on the part of David and Tom
> about what this code was trying to accomplish, but the fact that the
> code caused some confusion does
On Thu, Aug 16, 2018 at 12:36 PM, Alvaro Herrera
wrote:
> I have to admit I have a hard time understanding this stuff. I don't
> know what a "scan/join target" is (or scan/join relation for that
> matter) ... and this "tlist relation" thing is an entirely new concept
> to me.
Well, I invented
On 2018-Aug-13, Robert Haas wrote:
> In my original design, apply_scanjoin_target_to_paths() -- or whatever
> I called it in the original patch versions -- built an entirely new
> RelOptInfo, so that we ended up with one RelOptInfo representing the
> unvarnished result of scan/join planning, and
On Sat, Aug 11, 2018 at 9:16 AM, David Rowley
wrote:
> I started debugging this to see where things go wrong. I discovered
> that add_paths_to_append_rel() is called yet again from
> apply_scanjoin_target_to_paths() and this is where it's all going
> wrong. The problem is that the gather paths
On Wed, Aug 8, 2018 at 11:33 PM, Tom Lane wrote:
> Oh ... never mind that last. The parent Append will run its children
> sequentially, so that the Gathers execute one at a time, and at no
> point will more than 2 workers be active.
Yep.
> Nonetheless, it's a damfool query plan, because we'll
On 9 August 2018 at 15:33, Tom Lane wrote:
> Nonetheless, it's a damfool query plan, because we'll be going through
> parallel worker startup/shutdown overhead 4 times for no benefit.
> We really should put in some kind of logic to force those sibling
> Gathers to be aggregated into one, or else
I wrote:
> Now that seems to me to be a rather weird plan: why doesn't it prefer
> to flatten everything into one parallel append? Indeed, if you take
> out any of the remaining query parts such as the LIMIT, that's what
> it does. I think that its willingness to do this is actually kind
> of a
I spent some more time poking at Jaime's example. I can reduce the
problem query to this and still get the Assert crash:
select random()
from radicado tablesample bernoulli (9.7)
where radi_texto = radi_inst_actu
limit 33;
None of the elements of this query can be removed without causing the
On Thu, Aug 2, 2018 at 8:42 PM, David Rowley
wrote:
> Wouldn't that code have more flexibility to flatten the Append if it
> were to, instead of looking at the Append's subpaths, look at the
> subpath's Parent RelOptInfo paths and just use the Append and
> MergeAppend as a container to identify
On 3 August 2018 at 07:53, Robert Haas wrote:
> I don't really understand the issue at hand, but let me just make a
> comment about accumulate_append_subpath(). If we have a regular
> Append on top of another regular Append or on top of a MergeAppend, we
> can flatten the lower Merge(Append)
On 3 August 2018 at 05:54, Tom Lane wrote:
> Yeah, looking at the explain posted upthread, the issue is specifically
> that some of the child paths might be for Gathers over subsets of the
> partitioning hierarchy. It's not real clear to me whether such a subset
> would necessarily correspond to
David Rowley writes:
>> It's probably best discussed on the other thread, but it seems to be
>> by design in accumulate_append_subpath(). Parallel Append nodes don't
>> get flattened if they contain a mix of parallel aware and non-parallel
>> aware subplans.
I don't really understand the issue
On Thu, Aug 2, 2018 at 1:54 PM, Tom Lane wrote:
> (EXPLAIN isn't a very adequate tool for testing this, since
> it fails to show anything about what pruning tests are attached to an
> Append. I wonder if we need to create something that does show that.)
I've asked for that more than once and
[ bringing this discussion back to the original thread ]
David Rowley writes:
> The attached patch removes the Assert, but I think it should be
> probably be done as part of [1]'s patch since that's also adding the
> code to handle subplans for tables that don't belong in the partition
>
On 31 July 2018 at 11:25, Alvaro Herrera wrote:
> Not looking at the code right now either, but removing that assert and
> then removing the TABLESAMPLE clause, the query returns identical
> results with and without pruning, so maybe you're right. No time for
> further looking now.
I thought
On 2018-Jul-25, David Rowley wrote:
> Thinking again about the patch I submitted upthread; I wonder if it's
> actually possible to support pruning with Jamie's query. Without
> looking at the code, I don't quite see the reason that the
> sub-partitioned table wouldn't be correctly pruned by the
David Rowley writes:
> On 24 July 2018 at 16:55, Jaime Casanova
> wrote:
>> I was trying sqlsmith on REL_11_STABLE (commit
>> 1b957e59b92dc44c14708762f882d7910463a9ac) with a database i have at
>> hand, and got an assertion failure.
> In this case, the 2nd to 5th Append subplan's parents are
On 24 July 2018 at 16:55, Jaime Casanova wrote:
> I was trying sqlsmith on REL_11_STABLE (commit
> 1b957e59b92dc44c14708762f882d7910463a9ac) with a database i have at
> hand, and got an assertion failure.
> It seems to happen during planning on prunning time but only when
> tables get bigger than
Hi,
I was trying sqlsmith on REL_11_STABLE (commit
1b957e59b92dc44c14708762f882d7910463a9ac) with a database i have at
hand, and got an assertion failure.
It seems to happen during planning on prunning time but only when
tables get bigger than certain size.
I configured it with "--enable-debug
25 matches
Mail list logo
