On 27/7/2025 00:51, Alexander Korotkov wrote:
On Tue, Jul 22, 2025 at 2:13 PM Andrei Lepikhov I've another idea. cost_tuplesort() puts 2.0 under logarithm to prefer
tuplesort over heapsort. I think we can adjust cost_gather_merge() and
cost_merge_append() to do the same. 0001 patch implements
On Tue, Jul 22, 2025 at 2:13 PM Andrei Lepikhov wrote:
>
> On 4/6/2025 00:41, Alexander Korotkov wrote:
> > On Tue, Jun 3, 2025 at 5:35 PM Andrei Lepikhov
wrote:
> >> For me, it seems like a continuation of the 7d8ac98 discussion. We may
> >> charge a small fee for MergeAppend to adjust the balan
On 4/6/2025 00:41, Alexander Korotkov wrote:
On Tue, Jun 3, 2025 at 5:35 PM Andrei Lepikhov wrote:
For me, it seems like a continuation of the 7d8ac98 discussion. We may
charge a small fee for MergeAppend to adjust the balance, of course.
However, I think this small change requires a series of
On 4/6/2025 00:41, Alexander Korotkov wrote:
On Tue, Jun 3, 2025 at 5:35 PM Andrei Lepikhov wrote:
On 3/6/2025 16:05, Alexander Korotkov wrote:
On Tue, Jun 3, 2025 at 4:53 PM Andrei Lepikhov wrote:
Additionally, as I mentioned earlier, the primary reason for choosing
MergeAppend in the regre
On Tue, Jun 3, 2025 at 5:35 PM Andrei Lepikhov wrote:
> On 3/6/2025 16:05, Alexander Korotkov wrote:
> > On Tue, Jun 3, 2025 at 4:53 PM Andrei Lepikhov wrote:
> >> Additionally, as I mentioned earlier, the primary reason for choosing
> >> MergeAppend in the regression test was a slight total cost
On 3/6/2025 16:05, Alexander Korotkov wrote:
On Tue, Jun 3, 2025 at 4:53 PM Andrei Lepikhov wrote:
Additionally, as I mentioned earlier, the primary reason for choosing
MergeAppend in the regression test was a slight total cost difference
that triggered the startup cost comparison.
May you show
On Tue, Jun 3, 2025 at 4:53 PM Andrei Lepikhov wrote:
> On 3/6/2025 15:38, Alexander Korotkov wrote:
> > On Tue, Jun 3, 2025 at 4:23 PM Andrei Lepikhov wrote:
> >> To establish a stable foundation for discussion, I conducted simple
> >> tests - see, for example, a couple of queries in the attachm
On 3/6/2025 15:38, Alexander Korotkov wrote:
On Tue, Jun 3, 2025 at 4:23 PM Andrei Lepikhov wrote:
To establish a stable foundation for discussion, I conducted simple
tests - see, for example, a couple of queries in the attachment. As I
see it, Sort->Append works faster: in my test bench, it ta
On Tue, Jun 3, 2025 at 4:23 PM Andrei Lepikhov wrote:
> On 2/6/2025 20:21, Alexander Korotkov wrote:
> > I have the following question. I see patch changes some existing
> > plans from Sort(Append(...)) to MergeAppend(Sort(), ..., Sort(...)) or
> > even Materialize(MergeAppend(Sort(), ..., Sort(.
On 2/6/2025 20:21, Alexander Korotkov wrote:
I have the following question. I see patch changes some existing
plans from Sort(Append(...)) to MergeAppend(Sort(), ..., Sort(...)) or
even Materialize(MergeAppend(Sort(), ..., Sort(...))). This should be
some problem in cost_sort(). Otherwise, tha
Hi, Alexander!
On Wed, May 7, 2025 at 12:06 PM Alexander Pyhalov
wrote:
> Andrei Lepikhov писал(а) 2025-05-07 12:03:
> > On 7/5/2025 08:57, Alexander Pyhalov wrote:
> >> Andrei Lepikhov писал(а) 2025-05-07 08:02:
> >>> On 5/5/2025 15:56, Alexander Pyhalov wrote:
> Andrei Lepikhov писал(а) 20
Andrei Lepikhov писал(а) 2025-05-07 12:03:
On 7/5/2025 08:57, Alexander Pyhalov wrote:
Andrei Lepikhov писал(а) 2025-05-07 08:02:
On 5/5/2025 15:56, Alexander Pyhalov wrote:
Andrei Lepikhov писал(а) 2025-05-05 14:38:
Also logic a bit differs if path is NULL. In
get_cheapest_path_for_pathkeys_
On 7/5/2025 08:57, Alexander Pyhalov wrote:
Andrei Lepikhov писал(а) 2025-05-07 08:02:
On 5/5/2025 15:56, Alexander Pyhalov wrote:
Andrei Lepikhov писал(а) 2025-05-05 14:38:
Also logic a bit differs if path is NULL. In
get_cheapest_path_for_pathkeys_ext() we explicitly check for path
being NU
Andrei Lepikhov писал(а) 2025-05-07 08:02:
On 5/5/2025 15:56, Alexander Pyhalov wrote:
Andrei Lepikhov писал(а) 2025-05-05 14:38:
Also logic a bit differs if path is NULL. In
get_cheapest_path_for_pathkeys_ext() we explicitly check for path
being NULL, in get_cheapest_fractional_path_for_pathk
On 5/5/2025 15:56, Alexander Pyhalov wrote:
Andrei Lepikhov писал(а) 2025-05-05 14:38:
Also logic a bit differs if path is NULL. In
get_cheapest_path_for_pathkeys_ext() we explicitly check for path being
NULL, in get_cheapest_fractional_path_for_pathkeys_ext() only after
calculating sort cost.
Andrei Lepikhov писал(а) 2025-05-05 14:38:
On 4/29/25 19:25, Alexander Pyhalov wrote:
Andrei Lepikhov писал(а) 2025-04-29 16:52:
But it seems, base_path can't be NULL
Correct. Fixed.
Also we check base_path for required_outer and require_parallel_safe,
but if cheapest path for pathkeys is N
On 5/5/25 13:38, Andrei Lepikhov wrote:
Let's check next version of the patch in the attachment.
Oops, I forgot some tails - see this new version.
--
regards, Andrei LepikhovFrom 7b312c38bf9f2370c970dc0058d38610cb1ae6c6 Mon Sep 17 00:00:00 2001
From: "Andrei V. Lepikhov"
Date: Thu, 24 Apr 2025
On 4/29/25 19:25, Alexander Pyhalov wrote:
Andrei Lepikhov писал(а) 2025-04-29 16:52:
But it seems, base_path can't be NULL
Correct. Fixed.
Also we check base_path for required_outer and require_parallel_safe,
but if cheapest path for pathkeys is NULL, these checks are not
performed.
Than
Andrei Lepikhov писал(а) 2025-04-29 16:52:
On 4/25/25 17:13, Andrei Lepikhov wrote:
On 4/25/25 11:16, Alexander Pyhalov wrote:
Usually, sorted cheapest_total_path will be cheaper than sorted
fractional/startup path at least by startup cost (as after sorting it
includes total_cost of input path
On 4/25/25 17:13, Andrei Lepikhov wrote:
On 4/25/25 11:16, Alexander Pyhalov wrote:
Usually, sorted cheapest_total_path will be cheaper than sorted
fractional/startup path at least by startup cost (as after sorting it
includes total_cost of input path). But we ignore this case when
selecting c
On 4/25/25 11:16, Alexander Pyhalov wrote:
Andrei Lepikhov писал(а) 2025-04-24 16:01:
On 3/28/25 09:19, Alexander Pyhalov wrote:
In the attachment, see the patch written according to the idea. There
are I introduced two new routines:
get_cheapest_path_for_pathkeys_ext
get_cheapest_fractional_p
Andrei Lepikhov писал(а) 2025-04-24 16:01:
On 3/28/25 09:19, Alexander Pyhalov wrote:
Andy Fan писал(а) 2024-10-17 03:33:
I've updated patch. One more interesting case which we found - when
fractional path is selected, it still can be more expensive than
sorted cheapest total path (as we look
On 3/28/25 09:19, Alexander Pyhalov wrote:
Andy Fan писал(а) 2024-10-17 03:33:
I've updated patch. One more interesting case which we found - when
fractional path is selected, it still can be more expensive than sorted
cheapest total path (as we look only on indexes whith necessary
pathkeys, n
Andy Fan писал(а) 2024-10-17 03:33:
Bruce Momjian writes:
Is this still being considered?
I'd +1 on this feature. I guess this would be more useful on parallel
case, where the Sort can be pushed down to parallel worker, and in the
distributed database case, where the Sort can be pushed down
Hi!
I've checked this thread and examples in it, and do not see stable
improvements
in base tests. Sometimes base tests are considerably slower with patch,
like:
explain analyze
select t1.* from matest0 t1, matest0 t2
where t1.b = t2.b and t2.c = t2.d
order by t1.b limit 10;
Bruce Momjian writes:
> Is this still being considered?
I'd +1 on this feature. I guess this would be more useful on parallel
case, where the Sort can be pushed down to parallel worker, and in the
distributed database case, where the Sort can be pushed down to multiple
nodes, at the result, the
Is this still being considered?
---
On Tue, Jun 18, 2024 at 07:45:09PM +0300, Alexander Pyhalov wrote:
> Hi.
>
> Now when planner finds suitable pathkeys in generate_orderedappend_paths(),
> it uses them, even if explicit
27 matches
Mail list logo
