On 28.03.2025 15:23, Alena Rybakina wrote:
I agree with your code in general, but to be honest, double qsort
confused me a little.
I understood why it is needed - we need to sort the elements so that
they stand next to each other if they can be assigned to the same
group, and then sort the
On 28.03.2025 02:18, Alexander Korotkov wrote:
Hi!
On Mon, Mar 24, 2025 at 2:46 PM Alena Rybakina
wrote:
I agree with Andrey's changes and think we should fix this, because otherwise
it might be inconvenient.
For example, without this changes we will have to have different test output
files
On 3/28/25 12:59, Alexander Korotkov wrote:
On Fri, Mar 28, 2025 at 1:32 PM Andrei Lepikhov wrote:
I don't think this is going to be CPU-consuming. I don't think this
is going to be measurable. This patch introduces one additional pass
over array of OrArgIndexMatch'es, and qsort of them. I th
On Fri, Mar 28, 2025 at 1:32 PM Andrei Lepikhov wrote:
> On 3/28/25 00:18, Alexander Korotkov wrote:
> > The attached patch changes the reordering algorithm of
> > group_similar_or_args() in the following way. We reorder each group
> > of similar clauses so that the first item of the group stays
On 3/28/25 00:18, Alexander Korotkov wrote:
The attached patch changes the reordering algorithm of
group_similar_or_args() in the following way. We reorder each group
of similar clauses so that the first item of the group stays in place,
but all the other items are moved after it. So, if there
Hi, Alexander!
d4378c0005e61b1bb7
On Fri, 28 Mar 2025 at 03:18, Alexander Korotkov wrote:
>
> Hi!
>
> On Mon, Mar 24, 2025 at 2:46 PM Alena Rybakina
> wrote:
> > I agree with Andrey's changes and think we should fix this, because
> > otherwise it might be inconvenient.
> > For example, without
Hi!
On Mon, Mar 24, 2025 at 2:46 PM Alena Rybakina
wrote:
> I agree with Andrey's changes and think we should fix this, because otherwise
> it might be inconvenient.
> For example, without this changes we will have to have different test output
> files for the same query for different versions
On 24.03.2025 13:46, Pavel Borisov wrote:
Hi, Andrei!
On Mon, 24 Mar 2025 at 14:10, Andrei Lepikhov wrote:
Hi,
Playing with the feature, I found a slightly irritating permutation -
even if this code doesn't group any clauses, it may permute positions of
the quals. See:
DROP TABLE IF EXISTS m
Hi,
Playing with the feature, I found a slightly irritating permutation -
even if this code doesn't group any clauses, it may permute positions of
the quals. See:
DROP TABLE IF EXISTS main_tbl;
CREATE TABLE main_tbl(id bigint, hundred int, thousand int);
CREATE INDEX mt_hundred_ix ON main_tbl
Hi, Andrei!
On Mon, 24 Mar 2025 at 14:10, Andrei Lepikhov wrote:
>
> Hi,
>
> Playing with the feature, I found a slightly irritating permutation -
> even if this code doesn't group any clauses, it may permute positions of
> the quals. See:
>
> DROP TABLE IF EXISTS main_tbl;
> CREATE TABLE main_tb
On Mon, 3 Feb 2025 at 15:54, Alena Rybakina wrote:
>
>
> On 03.02.2025 14:32, Alexander Korotkov wrote:
>
> On Mon, Feb 3, 2025 at 12:22 PM Alena Rybakina
> wrote:
>
> Thank you for updated version! I agree for your version of the code.
>
> On 02.02.2025 21:00, Alexander Korotkov wrote:
>
> On Fr
On 03.02.2025 14:32, Alexander Korotkov wrote:
On Mon, Feb 3, 2025 at 12:22 PM Alena Rybakina
wrote:
Thank you for updated version! I agree for your version of the code.
On 02.02.2025 21:00, Alexander Korotkov wrote:
On Fri, Jan 31, 2025 at 4:31 PM Alena Rybakina
wrote:
I started reviewi
On Mon, Feb 3, 2025 at 12:22 PM Alena Rybakina
wrote:
>
> Thank you for updated version! I agree for your version of the code.
>
> On 02.02.2025 21:00, Alexander Korotkov wrote:
>
> On Fri, Jan 31, 2025 at 4:31 PM Alena Rybakina
> wrote:
>
> I started reviewing at the patch and saw some output "E
Thank you for updated version! I agree for your version of the code.
On 02.02.2025 21:00, Alexander Korotkov wrote:
On Fri, Jan 31, 2025 at 4:31 PM Alena Rybakina
wrote:
I started reviewing at the patch and saw some output "ERROR" in the output of
the test and is it okay here?
SELECT * FROM
On 2/3/25 00:57, Alexander Korotkov wrote:
On Thu, Jan 30, 2025 at 3:23 PM Pavel Borisov wrote:
On Tue, 28 Jan 2025 at 12:42, Andrei Lepikhov wrote:
On 1/28/25 11:36, Andrei Lepikhov wrote:
On 1/27/25 16:50, Alexander Korotkov wrote:
qsort(matches, n, sizeof(OrArgIndexMatch), or_arg_index_m
On Fri, Jan 31, 2025 at 4:31 PM Alena Rybakina
wrote:
> I started reviewing at the patch and saw some output "ERROR" in the output of
> the test and is it okay here?
>
> SELECT * FROM tenk1 t1
> WHERE t1.thousand = 42 OR t1.thousand = (SELECT t2.tenthous FROM tenk1 t2
> WHERE t2.thousand = t1.te
On Tue, Jan 28, 2025 at 10:42 AM Andrei Lepikhov wrote:
> On 1/28/25 11:36, Andrei Lepikhov wrote:
> > On 1/27/25 16:50, Alexander Korotkov wrote:
> > qsort(matches, n, sizeof(OrArgIndexMatch), or_arg_index_match_cmp);
> >
> > To fit an index, the order of elements in the target array of the
> > `
On Thu, Jan 30, 2025 at 3:23 PM Pavel Borisov wrote:
> On Tue, 28 Jan 2025 at 12:42, Andrei Lepikhov wrote:
> >
> > On 1/28/25 11:36, Andrei Lepikhov wrote:
> > > On 1/27/25 16:50, Alexander Korotkov wrote:
> > > qsort(matches, n, sizeof(OrArgIndexMatch), or_arg_index_match_cmp);
> > >
> > > To f
Hi!
On 25.01.2025 08:04, Alexander Korotkov wrote:
On Wed, Jan 15, 2025 at 10:24 AM Andrei Lepikhov wrote:
On 1/13/25 10:39, Andrei Lepikhov wrote:
On 1/13/25 01:39, Alexander Korotkov wrote:
It can be resolved with a single-line change (see attached). But I need
some time to ponder over the
On Tue, 28 Jan 2025 at 12:42, Andrei Lepikhov wrote:
>
> On 1/28/25 11:36, Andrei Lepikhov wrote:
> > On 1/27/25 16:50, Alexander Korotkov wrote:
> > qsort(matches, n, sizeof(OrArgIndexMatch), or_arg_index_match_cmp);
> >
> > To fit an index, the order of elements in the target array of the
> > `S
On 1/28/25 11:36, Andrei Lepikhov wrote:
On 1/27/25 16:50, Alexander Korotkov wrote:
qsort(matches, n, sizeof(OrArgIndexMatch), or_arg_index_match_cmp);
To fit an index, the order of elements in the target array of the
`ScalarArrayOpExpr` may change compared to the initial list of OR
expressio
On 1/27/25 16:50, Alexander Korotkov wrote:
I expressed my point on this in [1]. We generally greedy about index
quals and there is no logic which prevent us from using a clause and
index qual because of its cost. And there are many cases when this
causes regressions before d4378c0005. One o
Hi, Andrei!
On Mon, Jan 27, 2025 at 10:52 AM Andrei Lepikhov wrote:
> On 1/25/25 12:04, Alexander Korotkov wrote:
> > On Wed, Jan 15, 2025 at 10:24 AM Andrei Lepikhov
wrote:
> >> causes SEGFAULT during index keys evaluation. I haven't dived into it
> >> yet, but it seems quite a typical misstep
On 1/25/25 12:04, Alexander Korotkov wrote:
On Wed, Jan 15, 2025 at 10:24 AM Andrei Lepikhov wrote:
causes SEGFAULT during index keys evaluation. I haven't dived into it
yet, but it seems quite a typical misstep and is not difficult to fix.
Segfault appears to be caused by a typo. Patch used
On Wed, Jan 15, 2025 at 10:24 AM Andrei Lepikhov wrote:
> On 1/13/25 10:39, Andrei Lepikhov wrote:
> > On 1/13/25 01:39, Alexander Korotkov wrote:
> > It can be resolved with a single-line change (see attached). But I need
> > some time to ponder over the changing behaviour when a clause may match
On 1/13/25 10:39, Andrei Lepikhov wrote:
On 1/13/25 01:39, Alexander Korotkov wrote:
It can be resolved with a single-line change (see attached). But I need
some time to ponder over the changing behaviour when a clause may match
an index and be in joinorclauses.
In addition, let me raise a cou
On 1/13/25 01:39, Alexander Korotkov wrote:
The revised patch is attached. Most notably it revises
group_similar_or_args() to have the same notion of const-ness as
others. In that function we split potential index key and constant
early to save time on enumerating all possible index keys. But
On Mon, Jan 13, 2025 at 2:47 AM Yura Sokolov wrote:
> Вс, 12 янв. 2025 г. в 21:39, Alexander Korotkov :
>>
>> On Fri, Nov 29, 2024 at 9:54 AM Alexander Korotkov
>> wrote:
>> > On Fri, Nov 29, 2024 at 7:51 AM Alena Rybakina
>> > wrote:
>> > >
>> > > On 29.11.2024 03:04, Alexander Korotkov wrote:
Вс, 12 янв. 2025 г. в 21:39, Alexander Korotkov :On Fri, Nov 29, 2024 at 9:54 AM Alexander Korotkov wrote:
> On Fri, Nov 29, 2024 at 7:51 AM Alena Rybakina
> wrote:
> >
> > On 29.11.2024 03:04, Alexander Korotkov wrote:
> > > On Thu, Nov 28, 2024 at 9:33 PM Alena Rybakina
> > > wrote:
> > >> On
Hi!
On 12.01.2025 21:39, Alexander Korotkov wrote:
On Fri, Nov 29, 2024 at 9:54 AM Alexander Korotkov wrote:
On Fri, Nov 29, 2024 at 7:51 AM Alena Rybakina
wrote:
On 29.11.2024 03:04, Alexander Korotkov wrote:
On Thu, Nov 28, 2024 at 9:33 PM Alena Rybakina
wrote:
On 28.11.2024 22:28, Rani
On Fri, Nov 29, 2024 at 9:54 AM Alexander Korotkov wrote:
> On Fri, Nov 29, 2024 at 7:51 AM Alena Rybakina
> wrote:
> >
> > On 29.11.2024 03:04, Alexander Korotkov wrote:
> > > On Thu, Nov 28, 2024 at 9:33 PM Alena Rybakina
> > > wrote:
> > >> On 28.11.2024 22:28, Ranier Vilela wrote:
> > >>
> >
On Fri, Nov 29, 2024 at 7:51 AM Alena Rybakina
wrote:
>
> On 29.11.2024 03:04, Alexander Korotkov wrote:
> > On Thu, Nov 28, 2024 at 9:33 PM Alena Rybakina
> > wrote:
> >> On 28.11.2024 22:28, Ranier Vilela wrote:
> >>
> >> Em qui., 28 de nov. de 2024 às 16:03, Alena Rybakina
> >> escreveu:
> >
On 29.11.2024 03:04, Alexander Korotkov wrote:
On Thu, Nov 28, 2024 at 9:33 PM Alena Rybakina
wrote:
On 28.11.2024 22:28, Ranier Vilela wrote:
Em qui., 28 de nov. de 2024 às 16:03, Alena Rybakina
escreveu:
Hi! Thank you for the case.
On 28.11.2024 21:00, Alexander Lakhin wrote:
Hello Alex
On 11/29/24 07:04, Alexander Korotkov wrote:
On Thu, Nov 28, 2024 at 9:33 PM Alena Rybakina
I slightly revised the fix and added similar check to
group_similar_or_args(). Could you, please, review that before
commit?
LGTM,
As I see, we didn't pay attention to this option from the beginning.
Th
On Thu, Nov 28, 2024 at 9:33 PM Alena Rybakina
wrote:
>
> On 28.11.2024 22:28, Ranier Vilela wrote:
>
> Em qui., 28 de nov. de 2024 às 16:03, Alena Rybakina
> escreveu:
>>
>> Hi! Thank you for the case.
>>
>> On 28.11.2024 21:00, Alexander Lakhin wrote:
>> > Hello Alexander,
>> >
>> > 21.11.2024
On 28.11.2024 22:28, Ranier Vilela wrote:
Em qui., 28 de nov. de 2024 às 16:03, Alena Rybakina
escreveu:
Hi! Thank you for the case.
On 28.11.2024 21:00, Alexander Lakhin wrote:
> Hello Alexander,
>
> 21.11.2024 09:34, Alexander Korotkov wrote:
>> I'm going to push thi
Em qui., 28 de nov. de 2024 às 16:03, Alena Rybakina <
a.rybak...@postgrespro.ru> escreveu:
> Hi! Thank you for the case.
>
> On 28.11.2024 21:00, Alexander Lakhin wrote:
> > Hello Alexander,
> >
> > 21.11.2024 09:34, Alexander Korotkov wrote:
> >> I'm going to push this if no objections.
> >
> >
Sorry, I was in a hurry and forgot to add the test result. I updated the
patch
On 28.11.2024 22:03, Alena Rybakina wrote:
Hi! Thank you for the case.
On 28.11.2024 21:00, Alexander Lakhin wrote:
Hello Alexander,
21.11.2024 09:34, Alexander Korotkov wrote:
I'm going to push this if no object
Hi! Thank you for the case.
On 28.11.2024 21:00, Alexander Lakhin wrote:
Hello Alexander,
21.11.2024 09:34, Alexander Korotkov wrote:
I'm going to push this if no objections.
Please look at the following query, which triggers an error after
ae4569161:
SET random_page_cost = 1;
CREATE TABLE
Hello Alexander,
21.11.2024 09:34, Alexander Korotkov wrote:
I'm going to push this if no objections.
Please look at the following query, which triggers an error after ae4569161:
SET random_page_cost = 1;
CREATE TABLE tbl(u UUID);
CREATE INDEX idx ON tbl USING HASH (u);
SELECT COUNT(*) FROM tb
On 11/25/24 14:08, Alexander Korotkov wrote:
Hi, Richard!
On Mon, Nov 25, 2024 at 8:28 AM Richard Guo wrote:
On Thu, Nov 21, 2024 at 3:34 PM Alexander Korotkov wrote:
I'm going to push this if no objections.
Here is an Assert failure in match_orclause_to_indexcol.
create table t (a int);
Hi, Richard!
On Mon, Nov 25, 2024 at 8:28 AM Richard Guo wrote:
> On Thu, Nov 21, 2024 at 3:34 PM Alexander Korotkov
> wrote:
> > I'm going to push this if no objections.
>
> Here is an Assert failure in match_orclause_to_indexcol.
>
> create table t (a int);
> create index on t (a);
>
> # expl
On Thu, Nov 21, 2024 at 3:34 PM Alexander Korotkov wrote:
> I'm going to push this if no objections.
Here is an Assert failure in match_orclause_to_indexcol.
create table t (a int);
create index on t (a);
# explain select * from t where a <= 0 or a <= 1;
server closed the connection unexpectedl
looking at it again. in match_orclause_to_indexcol
/* Only the operator returning a boolean suits the transformation. */
if (get_op_rettype(opno) != BOOLOID)
break;
can change to
if (subClause->opresulttype != BOOLOID)
break;
for saving some cycle
On Wed, Nov 20, 2024 at 8:20 AM Andrei Lepikhov wrote:
> On 18/11/2024 06:19, Alexander Korotkov wrote:
> > On Fri, Nov 15, 2024 at 3:27 PM Alexander Korotkov
> > wrote:
> > Here is the next revision of this patch. No material changes,
> > adjustments for comments and commit message.
> I have p
On 18/11/2024 06:19, Alexander Korotkov wrote:
On Fri, Nov 15, 2024 at 3:27 PM Alexander Korotkov wrote:
Here is the next revision of this patch. No material changes,
adjustments for comments and commit message.
I have passed through the code and found no issues. Maybe only phrase:
"eval_const
On Fri, Nov 15, 2024 at 3:27 PM Alexander Korotkov wrote:
> On Mon, Oct 28, 2024 at 6:55 PM Alena Rybakina
> wrote:
> > I may be wrong, but the original idea was to double-check the result with
> > the original expression.
> >
> > But I'm willing to agree with you. I think we should add transfor
Hi, Alena!
On Mon, Oct 28, 2024 at 6:55 PM Alena Rybakina
wrote:
> I may be wrong, but the original idea was to double-check the result with the
> original expression.
>
> But I'm willing to agree with you. I think we should add transformed rinfo
> variable through add_predicate_to_index_quals
Hi, Jian!
On Mon, Oct 28, 2024 at 9:19 AM jian he wrote:
>
> * NOTE: returns NULL if clause is an OR or AND clause; it is the
> * responsibility of higher-level routines to cope with those.
> */
> static IndexClause *
> match_clause_to_indexcol(PlannerInfo *root,
> Re
Hi, Jian! Thank you for your work on this topic!
On 28.10.2024 10:19, jian he wrote:
* NOTE: returns NULL if clause is an OR or AND clause; it is the
* responsibility of higher-level routines to cope with those.
*/
static IndexClause *
match_clause_to_indexcol(PlannerInfo *root,
* NOTE: returns NULL if clause is an OR or AND clause; it is the
* responsibility of higher-level routines to cope with those.
*/
static IndexClause *
match_clause_to_indexcol(PlannerInfo *root,
RestrictInfo *rinfo,
int indexcol,
On 10/17/24 03:39, Alexander Korotkov wrote:
On Wed, Oct 16, 2024 at 7:22 AM Andrei Lepikhov wrote:
On 10/12/24 21:25, Alexander Korotkov wrote:
I forgot to specify (COSTS OFF) for EXPLAINs in regression tests. Fixed in v42.
I've passed through the patch set.
Let me put aside the v42-0003
On Wed, Oct 16, 2024 at 7:22 AM Andrei Lepikhov wrote:
> On 10/12/24 21:25, Alexander Korotkov wrote:
> > I forgot to specify (COSTS OFF) for EXPLAINs in regression tests. Fixed in
> > v42.
> I've passed through the patch set.
>
> Let me put aside the v42-0003 patch—it looks debatable, and I ne
On 10/12/24 21:25, Alexander Korotkov wrote:
I forgot to specify (COSTS OFF) for EXPLAINs in regression tests. Fixed in v42.
I've passed through the patch set.
Let me put aside the v42-0003 patch—it looks debatable, and I need time
to analyse the change in regression tests caused by this pat
On Fri, Oct 11, 2024 at 7:15 PM Alexander Korotkov wrote:
>
> On Fri, Oct 11, 2024 at 4:20 PM Alexander Korotkov
> wrote:
>>
>> This is all for now. The feedback is welcome.
>
> Just figured out, I forgot the patchset itself. Here it goes.
I forgot to specify (COSTS OFF) for EXPLAINs in regre
On Fri, Oct 11, 2024 at 4:20 PM Alexander Korotkov
wrote:
> This is all for now. The feedback is welcome.
>
Just figured out, I forgot the patchset itself. Here it goes.
--
Regards,
Alexander Korotkov
Supabase
v41-0001-Transform-OR-clauses-to-SAOP-s-during-index-matc.patch
Description:
Hi, Robert!
Thank you so much for your very valuable review. It took some time to
address all the points. Hopefully I didn't miss anything.
On Fri, Oct 4, 2024 at 4:34 PM Robert Haas wrote:
> On Mon, Sep 23, 2024 at 7:11 AM Alexander Korotkov
wrote:
> > Makes sense. Please, check the attache
On 10/4/24 20:34, Robert Haas wrote:
On Mon, Sep 23, 2024 at 7:11 AM Alexander Korotkov wrote:
Makes sense. Please, check the attached patch freeing the consts list
while returning NULL from match_orclause_to_indexcol().
More generally, many of the comments in this patch seem to just
explain
On 10/4/24 22:00, Peter Geoghegan wrote:
I don't think that removing duplicated constants is all that
important, since we already do that during execution proper. The
nbtree code does this in _bt_preprocess_array_keys. It even does
things like merge together a pair of duplicate SAOPs against the
On Mon, Oct 7, 2024 at 5:06 PM jian he wrote:
> assume v40 is the latest version.
> in group_similar_or_args
> we can add a bool variable so
>
> boolmatched = false;
> foreach(lc, orargs)
> {
> if (match_index_to_operand(nonConstExpr, colnum, index))
> {
>
Hi, Jian!
Thank you for your feedback.
On Tue, Oct 8, 2024 at 8:12 AM jian he wrote:
>
> On Mon, Oct 7, 2024 at 10:06 PM jian he wrote:
> >
> > assume v40 is the latest version.
>
> make_bitmap_paths_for_or_group
> {
> /*
> * First, try to match the whole group to the one index.
>
On Mon, Oct 7, 2024 at 10:06 PM jian he wrote:
>
> assume v40 is the latest version.
make_bitmap_paths_for_or_group
{
/*
* First, try to match the whole group to the one index.
*/
orargs = list_make1(ri);
indlist = build_paths_for_OR(root, rel,
On Mon, Oct 7, 2024 at 12:02 PM Tom Lane wrote:
> Peter Geoghegan writes:
> > To be clear, I don't think that it's essential that we have equivalent
> > behavior in those cases where the patch applies its transformations. I
> > have no objections to committing the patch without any handling for
>
On Mon, Oct 7, 2024 at 12:02 PM Tom Lane wrote:
> Peter Geoghegan writes:
> > To be clear, I don't think that it's essential that we have equivalent
> > behavior in those cases where the patch applies its transformations. I
> > have no objections to committing the patch without any handling for
>
On Mon, Oct 7, 2024 at 12:02 PM Tom Lane wrote:
> Oy. I don't agree with that *at all*. An "optimization" that changes
> query semantics is going to be widely seen as a bug.
I don't believe that I said otherwise?
It's just rather unclear what query semantics really mean here, in
detail. At lea
Peter Geoghegan writes:
> To be clear, I don't think that it's essential that we have equivalent
> behavior in those cases where the patch applies its transformations. I
> have no objections to committing the patch without any handling for
> that.
Oy. I don't agree with that *at all*. An "optim
On Fri, Oct 4, 2024 at 2:40 PM Robert Haas wrote:
>
> On Fri, Oct 4, 2024 at 2:20 PM Peter Geoghegan wrote:
> > On Fri, Oct 4, 2024 at 2:00 PM Alexander Korotkov
> > wrote:
> > > Yes, transformAExprIn() does the work to coerce all the expressions in
> > > the right part to the same type. Simil
assume v40 is the latest version.
in group_similar_or_args
we can add a bool variable so
boolmatched = false;
foreach(lc, orargs)
{
if (match_index_to_operand(nonConstExpr, colnum, index))
{
matches[i].indexnum = indexnum;
On Fri, Oct 4, 2024 at 4:34 PM Robert Haas wrote:
> On Mon, Sep 23, 2024 at 7:11 AM Alexander Korotkov
> wrote:
> > Makes sense. Please, check the attached patch freeing the consts list
> > while returning NULL from match_orclause_to_indexcol().
>
> Some review comments:
>
> I agree with the co
On Fri, Oct 4, 2024 at 9:40 PM Robert Haas wrote:
> On Fri, Oct 4, 2024 at 2:20 PM Peter Geoghegan wrote:
> > On Fri, Oct 4, 2024 at 2:00 PM Alexander Korotkov
> > wrote:
> > > Yes, transformAExprIn() does the work to coerce all the expressions in
> > > the right part to the same type. Similar
On Fri, Oct 4, 2024 at 9:20 PM Peter Geoghegan wrote:
> On Fri, Oct 4, 2024 at 2:00 PM Alexander Korotkov
> wrote:
> > Yes, transformAExprIn() does the work to coerce all the expressions in
> > the right part to the same type. Similar logic could be implemented
> > in match_orclause_to_indexcol
On Fri, Oct 4, 2024 at 2:20 PM Peter Geoghegan wrote:
> On Fri, Oct 4, 2024 at 2:00 PM Alexander Korotkov
> wrote:
> > Yes, transformAExprIn() does the work to coerce all the expressions in
> > the right part to the same type. Similar logic could be implemented
> > in match_orclause_to_indexcol
On Fri, Oct 4, 2024 at 2:00 PM Alexander Korotkov wrote:
> Yes, transformAExprIn() does the work to coerce all the expressions in
> the right part to the same type. Similar logic could be implemented
> in match_orclause_to_indexcol(). What worries me is whether it's
> quite late stage for this k
Hi, Peter!
Thank you very much for the feedback on this patch.
On Fri, Oct 4, 2024 at 8:44 PM Peter Geoghegan wrote:
> On Fri, Oct 4, 2024 at 7:45 AM Alexander Korotkov
> wrote:
> > Andrei, thank you for your opinion. Just for the record, I'm still
> > exploring this and will reply later toda
On Fri, Oct 4, 2024 at 7:45 AM Alexander Korotkov wrote:
> Andrei, thank you for your opinion. Just for the record, I'm still
> exploring this and will reply later today or tomorrow.
The logic that allows this to work for the case of IN() lists appears
in transformAExprIn(), which is in parse_ex
On Fri, Oct 4, 2024 at 10:24 AM Robert Haas wrote:
> Interesting. I would not have guessed that. I wonder how it works.
ISTM that we've established a general expectation that you as a user
can be fairly imprecise about which specific types you use as
constants in your query, while still getting a
On Thu, Oct 3, 2024 at 11:31 PM Andrei Lepikhov wrote:
> The origin reason was - to avoid multiple BitmapOr, which has some
> effects at the planning stage (memory consumption, planning time) and
> execution (execution time growth). IndexScan also works better with a
> single array (especially a h
On Fri, Oct 4, 2024 at 10:20 AM Peter Geoghegan wrote:
> The existing IN() syntax somehow manages to produce a useful bigint[]
> SAOP when I use the same mix of integer types/constants that were used
> for my original test case from yesterday:
Interesting. I would not have guessed that. I wonder
On Fri, Oct 4, 2024 at 8:31 AM Robert Haas wrote:
> Personally, I don't think this particular limitation is a problem. I
> don't think it will be terribly frequent in practice, and it doesn't
> seem any weirder than any of the other things that happen as a result
> of small and large integer const
On Mon, Sep 23, 2024 at 7:11 AM Alexander Korotkov wrote:
> Makes sense. Please, check the attached patch freeing the consts list
> while returning NULL from match_orclause_to_indexcol().
Some review comments:
I agree with the comments already given to the effect that the patch
looks much bette
On Thu, Oct 3, 2024 at 4:15 PM Peter Geoghegan wrote:
> Now that you're explicitly creating RestrictInfos for a particular
> index, I suppose that it might be easier to do this kind of thing --
> you have more context. Perhaps the patch can be made to recognize
> a mix of constants like this as al
On Fri, Oct 4, 2024 at 6:31 AM Andrei Lepikhov wrote:
>
> On 10/4/24 03:15, Peter Geoghegan wrote:
> > On Tue, Oct 1, 2024 at 6:25 AM Alexander Korotkov
> > wrote:
> >> I think this patchset got much better, and it could possible be
> >> committed after another round of cleanup and comment/docs
Hi!
On 03.10.2024 23:15, Peter Geoghegan wrote:
I do think that this patch got a lot better, and simpler, but I'm a
little worried about it not covering cases that are only very slightly
different to the ones that you're targeting. It's easiest to see what
I mean using an example.
After the sta
On 10/4/24 03:15, Peter Geoghegan wrote:
On Tue, Oct 1, 2024 at 6:25 AM Alexander Korotkov wrote:
I think this patchset got much better, and it could possible be
committed after another round of cleanup and comment/docs improvement.
It would be very kind if you share your view on the decisions
On Tue, Oct 1, 2024 at 6:25 AM Alexander Korotkov wrote:
> I think this patchset got much better, and it could possible be
> committed after another round of cleanup and comment/docs improvement.
> It would be very kind if you share your view on the decisions made in
> this patchset.
I do think t
On 1/10/2024 12:25, Alexander Korotkov wrote:
I think this patchset got much better, and it could possible be
committed after another round of cleanup and comment/docs improvement.
It would be very kind if you share your view on the decisions made in
this patchset.
I went through the code one mor
Hi Tom,
On Mon, Sep 23, 2024 at 2:10 PM Alexander Korotkov wrote:
> On Mon, Sep 16, 2024 at 3:44 PM Andrei Lepikhov wrote:
> > On 9/9/2024 12:36, Alexander Korotkov wrote:
> > > Also, I agree it get it's wrong to directly copy RestrictInfo struct
> > > in group_similar_or_args(). Instead, I've
On Mon, Sep 16, 2024 at 3:44 PM Andrei Lepikhov wrote:
> On 9/9/2024 12:36, Alexander Korotkov wrote:
> > Also, I agree it get it's wrong to directly copy RestrictInfo struct
> > in group_similar_or_args(). Instead, I've renamed
> > make_restrictinfo_internal() to make_plain_restrictinfo(), which
On 9/9/2024 12:36, Alexander Korotkov wrote:
Also, I agree it get it's wrong to directly copy RestrictInfo struct
in group_similar_or_args(). Instead, I've renamed
make_restrictinfo_internal() to make_plain_restrictinfo(), which is
intended to handle non-recursive cases when you've children alre
Hi!
On 09.09.2024 13:36, Alexander Korotkov wrote:
On Wed, Sep 4, 2024 at 6:42 PM Alena Rybakina wrote:
On 04.09.2024 18:31, Alena Rybakina wrote:
I rewrote the tests with integer types. Thanks for your suggestion. If
you don't mind, I've updated the diff file you attached earlier to
include
On Wed, Sep 4, 2024 at 6:42 PM Alena Rybakina wrote:
> On 04.09.2024 18:31, Alena Rybakina wrote:
> > I rewrote the tests with integer types. Thanks for your suggestion. If
> > you don't mind, I've updated the diff file you attached earlier to
> > include the tests.
> Sorry, I've just noticed that
On 04.09.2024 18:31, Alena Rybakina wrote:
I rewrote the tests with integer types. Thanks for your suggestion. If
you don't mind, I've updated the diff file you attached earlier to
include the tests.
Sorry, I've just noticed that one of your changes with the regression
test wasn't included. I f
Hi!
On 03.09.2024 12:52, Andrei Lepikhov wrote:
If OR constants have different types, then they belong to different
groups, and I think that's unfair. I think that conversion to a
single type should be used here - while I’m working on this, I’ll
send the code in the next letter.
IMO, that mean
On 26/8/2024 12:41, Alena Rybakina wrote:
On 26.08.2024 06:12, jian he wrote:
On Fri, Aug 23, 2024 at 8:58 PM Alexander Korotkov wrote:
+ int indexnum; /* index of the matching index */
+ int colnum; /* index of the matching column */
I am not 100% sure about the comments.
indexnum: index of
On Mon, Aug 26, 2024 at 6:41 PM Alena Rybakina
wrote:
>
> + /* Construct the list of nested OR arguments */
> + for (j = group_start; j < i; j++)
> + {
> + Node *arg = list_nth(orargs, matches[j].argindex);
> +
> + rargs = lappend(rargs, arg);
> + if (IsA(arg, RestrictInfo))
> + args = lappend(a
Hi!
On 26.08.2024 06:12, jian he wrote:
On Fri, Aug 23, 2024 at 8:58 PM Alexander Korotkov wrote:
based on v37.
+ {
+ /*
+ * We have only Const's. In this case we can construct an array
+ * directly.
+ */
+ int16 typlen;
+ bool typbyval;
+ char typalign;
+ Datum *elems;
+ int i = 0;
+ Arra
On Fri, Aug 23, 2024 at 8:58 PM Alexander Korotkov wrote:
>
based on v37.
+ {
+ /*
+ * We have only Const's. In this case we can construct an array
+ * directly.
+ */
+ int16 typlen;
+ bool typbyval;
+ char typalign;
+ Datum *elems;
+ int i = 0;
+ ArrayType *arrayConst;
+
+ get_typlenbyvalal
On 23/8/2024 14:58, Alexander Korotkov wrote:
On Fri, Aug 23, 2024 at 1:23 PM Andrei Lepikhov wrote:
The last query doesn't group clauses into two indexes. The reason is in
match_index_to_operand which classifies all 'x=' to one class. I'm not
sure because of overhead, but it may be resolved by
Sorry again.
The link to letter - -
https://www.postgresql.org/message-id/759292d5-cb51-4b12-89fa-576c1d9b374d%40postgrespro.ru
Patch -
https://www.postgresql.org/message-id/attachment/162897/v28-Transform-OR-clauses-to-ANY-expression.patch
On 24.08.2024 16:23, Alexander Korotkov wrote:
O
On Sat, Aug 24, 2024 at 4:08 PM Alena Rybakina
wrote:
> On 23.08.2024 19:38, Alexander Korotkov wrote:
> > Hi, Alena!
> >
> > On Fri, Aug 23, 2024 at 5:06 PM Alena Rybakina
> > wrote:
> >> To be fair, I fixed this before [0] by selecting the appropriate group
> >> of "or" expressions to transform
1 - 100 of 307 matches
Mail list logo
