On Wed, Jan 31, 2024 at 9:49 PM David Rowley wrote:
> Pushed to master.
>
> Thanks for the report and the fix, Alexander.
Thank you!
On Thu, 1 Feb 2024 at 04:32, Tom Lane wrote:
>
> Alvaro Herrera writes:
> > Since we have a minor coming up very soon, I think it's not a good idea
> > to backpatch right now. Maybe you can push to master now, and consider
> > whether to backpatch later.
>
> As a rule, we don't back-patch change
Alvaro Herrera writes:
> Since we have a minor coming up very soon, I think it's not a good idea
> to backpatch right now. Maybe you can push to master now, and consider
> whether to backpatch later.
As a rule, we don't back-patch changes like this ever. People don't
appreciate plans changing i
Hi,
>Since we have a minor coming up very soon, I think it's not a good idea
>to backpatch right now. Maybe you can push to master now, and consider
>whether to backpatch later.
>The problem is -- if somebody has an application that gets good plans
>with the current cost model, and you change th
On 2024-Jan-31, Alexander Kuzmenkov wrote:
> To put it another way, this change enables our usual cost model for
> MergeAppend to work correctly in the presence of filters. I think we
> can consider this model to be reasonably correct, and we don't
> currently have major problems with MergeAppend
On Wed, Jan 31, 2024 at 1:33 PM Alexander Kuzmenkov
wrote:
> I'd be happy to see this backpatched. What kind of regressions are we
> worried about? I'd say partition-wise sort + merge should be faster
> than append + sort for reasonably sized tables. That's basically what
> tuplesort does inside.
I'd be happy to see this backpatched. What kind of regressions are we
worried about? I'd say partition-wise sort + merge should be faster
than append + sort for reasonably sized tables. That's basically what
tuplesort does inside. Moreso, this can enable index scans on
partitions, which is an even
On Wed, Jan 31, 2024 at 12:12 PM David Rowley wrote:
>
> What is relevant are things like:
>
> For:
> * It's a clear bug and what's happening now is clearly wrong.
> * inheritance/partitioned table plan changes for the better in minor versions
>
> Against:
> * Nobody has complained for 13 years, s
On Wed, 31 Jan 2024 at 18:58, Ashutosh Bapat
wrote:
> with patch
> Merge Append (cost=6.94..18.90 rows=198 width=4)
> without patch
> Sort (cost=19.04..19.54 rows=198 width=4)
> Those numbers are higher than 1% (#define STD_FUZZ_FACTOR 1.01) but
> slight variation in all the GUCs that affect
On Wed, Jan 31, 2024 at 4:33 AM David Rowley wrote:
>
> On Wed, 31 Jan 2024 at 02:23, Alexander Kuzmenkov
> wrote:
> >
> > On Tue, Jan 30, 2024 at 1:20 PM David Rowley wrote:
> > > You should likely focus on trying to find a test that does not require
> > > making 2 tables with 10k rows.
> >
> >
On Wed, 31 Jan 2024 at 02:23, Alexander Kuzmenkov
wrote:
>
> On Tue, Jan 30, 2024 at 1:20 PM David Rowley wrote:
> > You should likely focus on trying to find a test that does not require
> > making 2 tables with 10k rows.
>
> Is 1k smallint OK? It should fit in one page. Still reproduces the
> e
On Tue, Jan 30, 2024 at 1:20 PM David Rowley wrote:
> You should likely focus on trying to find a test that does not require
> making 2 tables with 10k rows.
Is 1k smallint OK? It should fit in one page. Still reproduces the
error, and the entire test case runs in under 10 ms.
diff --git a/src/ba
On Wed, 31 Jan 2024 at 00:06, Alexander Kuzmenkov
wrote:
> Here is a small patch that reproduces the problem on two tables with
> inheritance, and fixes it. I'll add it to the Commitfest.
Good catch.
It seems to have been broken since MergeAppends were added in 11cad29c9.
The code fix looks goo
Hi,
> Here is a small patch that reproduces the problem on two tables with
> inheritance, and fixes it. I'll add it to the Commitfest.
Thanks for the patch.
I can confirm that it changes the plan from Sort + Append to MergeAppend.
Before:
```
explain (costs off) select * from ma0 where a < 100
Here is a small patch that reproduces the problem on two tables with
inheritance, and fixes it. I'll add it to the Commitfest.
On Tue, Jan 30, 2024 at 8:20 AM Ashutosh Bapat
wrote:
>
> On Mon, Jan 29, 2024 at 6:11 PM Alexander Kuzmenkov
> wrote:
> >
> > Hello hackers,
> >
> > While investigating
On Mon, Jan 29, 2024 at 6:11 PM Alexander Kuzmenkov
wrote:
>
> Hello hackers,
>
> While investigating some query plans, I noticed some code that seems
> to be wrong: when create_merge_append_path() estimates the cost of
> sorting an input, it calls cost_sort() passing subpath->parent->tuples
> as
Hello hackers,
While investigating some query plans, I noticed some code that seems
to be wrong: when create_merge_append_path() estimates the cost of
sorting an input, it calls cost_sort() passing subpath->parent->tuples
as the number of tuples. Shouldn't it use subpath->parent->rows or
even subp
17 matches
Mail list logo
