Hi folks,
Just wanted to mention, that looks like some CFBot test are failing,
something around level_tracking in pgss.
On 10/31/24 21:00, Alena Rybakina wrote:
On 29.10.2024 05:47, Andrei Lepikhov wrote:
I played around with the examples a bit and couldn't figure out
something. When I added the same values to different columns - firstly
in a, later in b, the order of the columns for sort operation doesn't
ch
I played around with the examples a bit and couldn't figure out
something. When I added the same values to different columns -
firstly in a, later in b, the order of the columns for sort operation
doesn't change. Isn't this a mistake?
create table a (x1 int, y1 int);
create table b (x2 int,
On 29.10.2024 05:47, Andrei Lepikhov wrote:
On 10/28/24 16:48, Alena Rybakina wrote:
On 23.10.2024 04:39, Andrei Lepikhov wrote:
On 15/10/2024 12:15, David Rowley wrote:
And the last patch is a demo of how I'm going to use the previous
three patches and add one more strategy to improve the ord
On 10/28/24 16:48, Alena Rybakina wrote:
On 23.10.2024 04:39, Andrei Lepikhov wrote:
On 15/10/2024 12:15, David Rowley wrote:
And the last patch is a demo of how I'm going to use the previous
three patches and add one more strategy to improve the order of
columns in the GROUP-BY clause.
To b
Hi! Thank you for your work on this subject!
On 23.10.2024 04:39, Andrei Lepikhov wrote:
On 15/10/2024 12:15, David Rowley wrote:
On Tue, 15 Oct 2024 at 17:48, Andrei Lepikhov wrote:
I think maybe what is worth working on is seeing if you can better
estimate the number of tiebreak comparisons
On 15/10/2024 12:15, David Rowley wrote:
On Tue, 15 Oct 2024 at 17:48, Andrei Lepikhov wrote:
I think maybe what is worth working on is seeing if you can better
estimate the number of tiebreak comparisons by checking the number of
distinct values for each sort key. That might require what we
di
On 10/15/24 12:15, David Rowley wrote:
As for your patch, I'm suspicious that the general idea you're
proposing is an actual improvement.
I didn't intend to treat it as an 'improvement' but as an intermediate
patch. The main purpose here is to debate the way & introduce
considering of number of
On Tue, 15 Oct 2024 at 17:48, Andrei Lepikhov wrote:
> I am suspicious of that but open to hearing other opinions. The
> coefficient incorporates knowledge about how many comparisons will be
> made with this sorting operator. The caller can have some additional
> knowledge about that. For example,
On 10/15/24 02:59, Kirill Reshke wrote:
On Thu, 22 Aug 2024 at 23:46, Andrei Lepikhov wrote:
Two questions:
Thank you for the interest to this feature!
1) Why do we change the `cost_sort` definition? We can calculate the
length of `pathkeys` inside cost_sort if we want, just like we do
inside
Hi!
On 14.10.2024 22:59, Kirill Reshke wrote:
The patch in the attachment is a simplistic attempt to differentiate
these sortings by the number of columns. It is not ideal because
comparisons depend on the duplicates in each column, but it may be the
subject of further work.
Even such a trivial
Hi!
On Thu, 22 Aug 2024 at 23:46, Andrei Lepikhov wrote:
>
> Hi,
>
> I would like to propose a slight elaboration of the sort cost model.
> In practice, we frequently see the choice of suboptimal sortings, which
> slump performance by 10-50%.
>
> The key reason here is the optimiser's blindness t
On 8/23/24 01:46, Andrei Lepikhov wrote:
Just a rebase onto current master to make cf-bot be happy.
--
regards, Andrei Lepikhov
From 73472897442516f0df4ed945cda28d125df08197 Mon Sep 17 00:00:00 2001
From: "Andrei V. Lepikhov"
Date: Tue, 8 Oct 2024 11:20:46 +0700
Subject: [PATCH v2] Introduce th
13 matches
Mail list logo
