On Fri, Jan 3, 2025 at 3:02 AM Robert Haas wrote:
>
> I think it's unhelpful that you keep calling this a "bug" when the
> behavior is clearly deliberate. Whether it's the *right* behavior is
> debatable, but it's not *accidental* behavior.
>
Ok, let's call it "not right" behaviour :). Let me fur
On Thu, Jan 2, 2025 at 3:58 PM Tom Lane wrote:
> I am wondering if the problem is not that the plan is slower, it's
> that for some reason the planner took a lot longer to create it.
> It's very plausible that partitionwise planning takes longer, and
> maybe we have some corner cases where the tim
Robert Haas writes:
> I'm obviously missing something here, because I'm sure Jakub is quite
> right when he says that this actually happened and actually hosed an
> EDB customer. But I don't understand HOW it happened, and I think if
> we're going to change the code we really ought to understand t
On Thu, Jan 2, 2025 at 4:41 AM Ashutosh Bapat
wrote:
> A join between partitions is pushed down if only partitionwise join is
> chosen and a join between partitions won't be pushed down if
> partitionwise join is not chosen. Hence this bug affects pushdown as
> well.
>
> The CF entry shows as wait
On Tue, Oct 1, 2024 at 3:22 AM Andrei Lepikhov wrote:
>
> On 24/7/2024 15:22, Ashutosh Bapat wrote:
> > On Wed, Jul 24, 2024 at 9:42 AM Richard Guo wrote:
> >> Is there a specific query that demonstrates benefits from this change?
> >> I'm curious about scenarios where a partitionwise join runs s
On 24/7/2024 15:22, Ashutosh Bapat wrote:
On Wed, Jul 24, 2024 at 9:42 AM Richard Guo wrote:
Is there a specific query that demonstrates benefits from this change?
I'm curious about scenarios where a partitionwise join runs slower
than a non-partitionwise join.
[1] provides a testcase where a
On Wed, Jul 24, 2024 at 9:42 AM Richard Guo wrote:
>
> On Wed, May 22, 2024 at 3:57 PM Ashutosh Bapat
> wrote:
> > I will create patches for the back-branches once the patch for master is in
> > a committable state.
>
> AFAIU, this patch prevents apply_scanjoin_target_to_paths() from
> discardin
On Wed, May 22, 2024 at 3:57 PM Ashutosh Bapat
wrote:
> I will create patches for the back-branches once the patch for master is in a
> committable state.
AFAIU, this patch prevents apply_scanjoin_target_to_paths() from
discarding old paths of partitioned joinrels. Therefore, we can
retain non-
On Tue, May 28, 2024 at 7:13 AM wrote:
> 1. I think the order by pk frac limit plans had just to similar
> performance behaviour for me to bother.
> But afaics the main point of your proposal is not related to frac plans
> at all.
>
Right.
> 2. We can't expect the optimizers to simply yield be
Hi Ashutosh!
On 2024-05-27 14:17, Ashutosh Bapat wrote:
On Fri, May 24, 2024 at 11:02 AM wrote:
Hi Ashutosh,
thanks for bringing this to my attention. I'll first share a few
thoughts about the change and respond regarding the test below.
I clearly understand your intention with this patch.
On Fri, May 24, 2024 at 11:02 AM wrote:
> Hi Ashutosh,
>
> thanks for bringing this to my attention. I'll first share a few
> thoughts about the change and respond regarding the test below.
>
> I clearly understand your intention with this patch. It's an issue I run
> into from time to time.
>
>
On Fri, May 24, 2024 at 2:02 PM wrote:
> I am not sure, whether it's really a bug. I personally wouldn't be brave
> enough to back patch this. I don't want to deal with complaining end
> users. Suddenly their optimizer, which always had horrible estimates,
> was actually able to do harmful stuff w
Hi Ashutosh,
thanks for bringing this to my attention. I'll first share a few
thoughts about the change and respond regarding the test below.
I clearly understand your intention with this patch. It's an issue I run
into from time to time.
I did some testing with some benchmark sets back wit
On Mon, May 6, 2024 at 6:28 PM Ashutosh Bapat
wrote:
>
>
> On Mon, May 6, 2024 at 4:26 PM Jakub Wartak
> wrote:
>
>> Hi Ashutosh & hackers,
>>
>> On Mon, Apr 15, 2024 at 9:00 AM Ashutosh Bapat
>> wrote:
>> >
>> > Here's patch with
>> >
>> [..]
>> > Adding to the next commitfest but better to co
On Mon, May 6, 2024 at 4:26 PM Jakub Wartak
wrote:
> Hi Ashutosh & hackers,
>
> On Mon, Apr 15, 2024 at 9:00 AM Ashutosh Bapat
> wrote:
> >
> > Here's patch with
> >
> [..]
> > Adding to the next commitfest but better to consider this for the next
> set of minor releases.
>
> 1. The patch does n
Hi Ashutosh & hackers,
On Mon, Apr 15, 2024 at 9:00 AM Ashutosh Bapat
wrote:
>
> Here's patch with
>
[..]
> Adding to the next commitfest but better to consider this for the next set of
> minor releases.
1. The patch does not pass cfbot -
https://cirrus-ci.com/task/5486258451906560 on master du
Here's patch with
On Thu, Apr 11, 2024 at 12:24 PM Ashutosh Bapat <
ashutosh.bapat@gmail.com> wrote:
>
>
> On Thu, Apr 11, 2024 at 12:07 PM Ashutosh Bapat <
> ashutosh.bapat@gmail.com> wrote:
>
>> Hi All,
>> Per below code and comment in apply_scanjoin_target_to_paths(), the
>> function z
On Thu, Apr 11, 2024 at 12:07 PM Ashutosh Bapat <
ashutosh.bapat@gmail.com> wrote:
> Hi All,
> Per below code and comment in apply_scanjoin_target_to_paths(), the
> function zaps all the paths of a partitioned relation.
> /*
> * If the rel is partitioned, we want to drop its existing paths and
Hi All,
Per below code and comment in apply_scanjoin_target_to_paths(), the
function zaps all the paths of a partitioned relation.
/*
* If the rel is partitioned, we want to drop its existing paths and
* generate new ones. This function would still be correct if we kept the
* existing paths: we'd
19 matches
Mail list logo
