On 03.04.2025 18:26, Alexander Korotkov wrote:
On Thu, Apr 3, 2025 at 5:18 PM Alena Rybakina wrote:
Okay, I agree with you.
Good. I've reflected this limitation in comments and the commit
message.
Thank you, it looks fine)
Also, I've adjust regression tests by removing excessive
ones and ad
On 02.04.2025 22:00, Alexander Korotkov wrote:
Hi, Alena!
On Wed, Apr 2, 2025 at 5:33 PM Alena Rybakina
wrote:
I prepared a patch according to my suggestions, it just checks
that the transformation is not carried out if there is a var
element, there are changes only in one test,
On 04.04.2025 19:00, Tom Lane wrote:
Peter Geoghegan writes:
Is somebody going to commit this soon? Alexander?
Done.
I thought the point of the test case was to check VALUES folding
on both sides of the join. I'm not sure why that's actually
a useful expenditure of test cycles, but Alena's p
On Fri, Apr 4, 2025 at 7:00 PM Tom Lane wrote:
> Peter Geoghegan writes:
> > Is somebody going to commit this soon? Alexander?
>
> Done.
>
> I thought the point of the test case was to check VALUES folding
> on both sides of the join. I'm not sure why that's actually
> a useful expenditure of te
On Fri, Apr 4, 2025 at 12:00 PM Tom Lane wrote:
> Peter Geoghegan writes:
> > Is somebody going to commit this soon? Alexander?
>
> Done.
Thanks!
> If it's still not stable I think the next step is to nuke both
> test queries, since I remain of the opinion that they're likely
> a waste of cycle
Peter Geoghegan writes:
> Is somebody going to commit this soon? Alexander?
Done.
I thought the point of the test case was to check VALUES folding
on both sides of the join. I'm not sure why that's actually
a useful expenditure of test cycles, but Alena's patch undid that
without adjusting the
On Fri, Apr 4, 2025 at 11:19 AM Alena Rybakina
wrote:
> I fixed it - changed the tables and didn't use system tables.
Is somebody going to commit this soon? Alexander?
--
Peter Geoghegan
On 04.04.2025 17:39, Andres Freund wrote:
On 2025-04-03 18:26:48 +0300, Alexander Korotkov wrote:
On Thu, Apr 3, 2025 at 5:18 PM Alena Rybakina wrote:
Okay, I agree with you.
Good. I've reflected this limitation in comments and the commit
message. Also, I've adjust regression tests by remov
Andres Freund writes:
> This just failed on both buildfarm and CI:
Yeah, the plan for that join seems fairly unstable. Is there
actually any need for the join to pg_am?
regards, tom lane
On 2025-04-03 18:26:48 +0300, Alexander Korotkov wrote:
> On Thu, Apr 3, 2025 at 5:18 PM Alena Rybakina
> wrote:
> > Okay, I agree with you.
>
> Good. I've reflected this limitation in comments and the commit
> message. Also, I've adjust regression tests by removing excessive
> ones and adding
On Thu, Apr 3, 2025 at 5:18 PM Alena Rybakina wrote:
> Okay, I agree with you.
Good. I've reflected this limitation in comments and the commit
message. Also, I've adjust regression tests by removing excessive
ones and adding more important cases. I'm going to push this if no
objections.
-
Hi, Alena!
On Wed, Apr 2, 2025 at 5:33 PM Alena Rybakina
wrote:
> I prepared a patch according to my suggestions, it just checks that the
> transformation is not carried out if there is a var element, there are
> changes only in one test, but I think it is correct.
>
> diff -U3
> /home/alena/pos
On 01.04.2025 17:23, Alena Rybakina wrote:
Hi, Alexander!
On 01.04.2025 15:07, Alexander Korotkov wrote:
Hi, Alena!
On Tue, Apr 1, 2025 at 2:11 AM Alena Rybakina
wrote:
4.1) explain analyze SELECT ten
FROM onek t WHERE unique1 IN ( VALUES (0), ((2 IN ( SELECT
unique2 FROM one
Hi, Alexander!
On 01.04.2025 15:07, Alexander Korotkov wrote:
Hi, Alena!
On Tue, Apr 1, 2025 at 2:11 AM Alena Rybakina
wrote:
4.1) explain analyze SELECT ten
FROM onek t WHERE unique1 IN ( VALUES (0), ((2 IN ( SELECT unique2
FROM onek c WHERE c.unique2 in ((values(0),(2::in
Hi, Alena!
On Tue, Apr 1, 2025 at 2:11 AM Alena Rybakina
wrote:
> 4.1) explain analyze SELECT ten
>
> FROM onek t WHERE unique1 IN ( VALUES (0), ((2 IN ( SELECT unique2 FROM
> onek c WHERE c.unique2 in ((values(0),(2::integer)) );
>
> QUERY PLAN
>
Hi, Alena!
On Tue, Apr 1, 2025 at 2:11 AM Alena Rybakina
wrote:
> Yes, I agree with that - this is precisely why we need to call
IncrementVarSublevelsUp() unconditionally for all types.
>
> As you mentioned earlier, Var nodes can be nested more deeply, and
skipping this step could lead to incorre
Hi, Alexander!
On 30.03.2025 00:59, Alexander Korotkov wrote:
Hi, Alena!
On Sat, Mar 29, 2025 at 9:03 PM Alena Rybakina
wrote:
On 29.03.2025 14:03, Alexander Korotkov wrote:
One thing I have to fix: we must do
IncrementVarSublevelsUp() unconditionally for all expressions as Vars
could be de
Hi, Alena!
On Sat, Mar 29, 2025 at 9:03 PM Alena Rybakina
wrote:
> On 29.03.2025 14:03, Alexander Korotkov wrote:
>> One thing I have to fix: we must do
>> IncrementVarSublevelsUp() unconditionally for all expressions as Vars
>> could be deeper inside.
>
> Yes, I'm looking at it too, I've just un
Hi!
On 29.03.2025 14:03, Alexander Korotkov wrote:
On Wed, Mar 12, 2025 at 8:11 PM Alena Rybakina
wrote:
On 06.03.2025 11:23, Alexander Korotkov wrote:
Hi, Alena!
On Sat, Mar 1, 2025 at 1:39 PM Alena Rybakina wrote:
On 09.02.2025 18:38, Alexander Korotkov wrote:
Also, aren't we too restr
On Wed, Mar 12, 2025 at 8:11 PM Alena Rybakina
wrote:
> On 06.03.2025 11:23, Alexander Korotkov wrote:
>
> Hi, Alena!
>
> On Sat, Mar 1, 2025 at 1:39 PM Alena Rybakina
> wrote:
>
> On 09.02.2025 18:38, Alexander Korotkov wrote:
>
> Also, aren't we too restrictive while requiring is_simple_values
Hi, Alexander!
On 06.03.2025 11:23, Alexander Korotkov wrote:
Hi, Alena!
On Sat, Mar 1, 2025 at 1:39 PM Alena Rybakina wrote:
On 09.02.2025 18:38, Alexander Korotkov wrote:
Also, aren't we too restrictive while requiring is_simple_values_sequence()?
For instance, I believe cases like this (c
Hi, Alena!
On Sat, Mar 1, 2025 at 1:39 PM Alena Rybakina wrote:
> On 09.02.2025 18:38, Alexander Korotkov wrote:
>>
>> Also, aren't we too restrictive while requiring is_simple_values_sequence()?
>> For instance, I believe cases like this (containing Var) could be
>> transformed too.
>>
>> selec
On 28.02.2025 14:48, Alena Rybakina wrote:
Hi!
On 21.02.2025 00:09, Alena Rybakina wrote:
Hi!
On 09.02.2025 18:38, Alexander Korotkov wrote:
Also, aren't we too restrictive while requiring is_simple_values_sequence()?
For instance, I believe cases like this (containing Var) could be transfo
Hi!
On 21.02.2025 00:09, Alena Rybakina wrote:
Hi!
On 09.02.2025 18:38, Alexander Korotkov wrote:
Also, aren't we too restrictive while requiring is_simple_values_sequence()?
For instance, I believe cases like this (containing Var) could be transformed
too.
select * from t t1, lateral (sele
The following review has been posted through the commitfest application:
make installcheck-world: tested, failed
Implements feature: tested, failed
Spec compliant: tested, failed
Documentation:tested, failed
Hi Ivan Kush
I tested the patch with `commands.sql` and obser
Hi!
On 09.02.2025 18:38, Alexander Korotkov wrote:
Also, aren't we too restrictive while requiring is_simple_values_sequence()?
For instance, I believe cases like this (containing Var) could be transformed
too.
select * from t t1, lateral (select * from t t2 where t2.i in (values (t1.i),
(1))
Hi! Thank you for your review!
On 09.02.2025 18:38, Alexander Korotkov wrote:
On Sun, Feb 9, 2025 at 1:58 PM Alexander Korotkov wrote:
On Thu, Jan 9, 2025 at 3:11 PM Alena Rybakina wrote:
On 04.10.2024 12:05, Andrei Lepikhov wrote:
We also have an implementation of VALUES -> ARRAY transform
On Sun, Feb 9, 2025 at 1:58 PM Alexander Korotkov wrote:
>
> On Thu, Jan 9, 2025 at 3:11 PM Alena Rybakina
> wrote:
> > On 04.10.2024 12:05, Andrei Lepikhov wrote:
> > > We also have an implementation of VALUES -> ARRAY transformation.
> > > Because enterprises must deal with users' problems, ma
Hi, Alena!
On Thu, Jan 9, 2025 at 3:11 PM Alena Rybakina
wrote:
> On 04.10.2024 12:05, Andrei Lepikhov wrote:
> > We also have an implementation of VALUES -> ARRAY transformation.
> > Because enterprises must deal with users' problems, many of these
> > users employ automatically generated querie
Hi!
On 04.10.2024 12:05, Andrei Lepikhov wrote:
We also have an implementation of VALUES -> ARRAY transformation.
Because enterprises must deal with users' problems, many of these
users employ automatically generated queries.
Being informed very well of the consensus about that stuff, we've
de
Hi Ivan,
I tested the patch using the input provided in commands.sql and observed
improvements in both planning and execution time. These optimizations are
especially noticeable when working with a mulitple tables. Even when querying
just a single table, there is a small improvement in planning
I agree, your realization is better: reliability is better and debugging
is simplier.
I've looked at the code, looks good to me. Only style notes like
VTA/VtA, SELECT/select, etc. may be corrected
On 10/4/24 12:15, Alena Rybakina wrote:
It was sent here [0].
[0]
https://www.postgresql.org/m
On 04.10.2024 11:43, Ivan Kush wrote:
Do you mean, that I should try to execute such command?
In this patch it gives ANY
postgres=# EXPLAIN (ANALYZE, COSTS OFF, SUMMARY OFF, TIMING OFF)
select * from table1
where fld2 in
(VALUES('\\230\\211\\030f\\332\\261R\\333\\021\\356\\337z5\\336\\032\\
On 10/4/24 04:08, Tom Lane wrote:
Laurenz Albe writes:
I wonder if it is worth the extra planning time to detect and improve
such queries.
I'm skeptical too. I'm *very* skeptical of implementing it in the
grammar as shown here --- I'd go so far as to say that that approach
cannot be accepted
Some ORMs or proprietary software may write it mistakenly. In these
cases this idea may be helpful.
This patch contains GUC to enable/disable this optimization
On 10/3/24 23:19, Laurenz Albe wrote:
On Thu, 2024-10-03 at 23:10 +0300, Alena Rybakina wrote:
On 03.10.2024 22:52, Ivan Kush wrote:
Do you mean, that I should try to execute such command?
In this patch it gives ANY
postgres=# EXPLAIN (ANALYZE, COSTS OFF, SUMMARY OFF, TIMING OFF)
select * from table1
where fld2 in
(VALUES('\\230\\211\\030f\\332\\261R\\333\\021\\356\\337z5\\336\\032\\372'::bytea),
('\\235\\204 \\004\\017\
Laurenz Albe writes:
> I wonder if it is worth the extra planning time to detect and improve
> such queries.
I'm skeptical too. I'm *very* skeptical of implementing it in the
grammar as shown here --- I'd go so far as to say that that approach
cannot be accepted. That's far too early, and it ri
On Thu, 2024-10-03 at 23:10 +0300, Alena Rybakina wrote:
> On 03.10.2024 22:52, Ivan Kush wrote:
> >
> > Hello, hackers! I with my friends propose the patch to replace IN
> > VALUES to ANY in WHERE clauses.
> >
> > # Intro
> >
> > The `VALUES` in the `IN VALUES` construct is replaced with with
Hi!
On 03.10.2024 22:52, Ivan Kush wrote:
Hello, hackers! I with my friends propose the patch to replace IN
VALUES to ANY in WHERE clauses.
# Intro
The `VALUES` in the `IN VALUES` construct is replaced with with an
array of values when `VALUES` contains 1 column. In the end it will be
rep
39 matches
Mail list logo
