was discussed at the Vancouver conference. What are
the open issues? I know of several:
* add tests that were requested by Fujii-san and now posted by
Alexander Pyhalov
* Where is the documentation? I know the original patch had some, and
I improved it, but it seems to be missing
t;T 1" r3 WHERE ((date(r3.c5) =
'1970-01-17'::date)) AND ((r1.c3 = r3.c3
Deparsing semi-joins leads to generating (text) conditions like 'EXISTS
(SELECT NULL FROM inner_rel WHERE join_conds) . Such conditions are
generated in deparseFromExprForRel() and distributed
xpected. As I see, we have
expression FuncExprdate(oid = 2029, args=Var ) = Const(type date)
(date(r3.c5) = '1970-01-17'::date).
Function is
# select proname, provolatile from pg_proc where oid=2029;
proname | provolatile
-+-
date| i
So it's shippable.
--
Best regards,
Alexander Pyhalov,
Postgres Professional
l fail for certain
cases, when remote server version is not the latest. In other cases we
tried
to preserve compatibility. Should we have a switch for a foreign server
to turn this optimization off? Or do we just state that users
should use different workarounds if remote server version d
Bruce Momjian писал 2023-06-05 19:26:
On Mon, Jun 5, 2023 at 12:00:27PM +0300, Alexander Pyhalov wrote:
Note that after these changes "select sum()" will fail for certain
cases,
when remote server version is not the latest. In other cases we tried
to preserve compatibility. Should
fujii.y...@df.mitsubishielectric.co.jp писал 2023-06-06 06:08:
Hi Mr.Pyhalov.
Thank you for your always thoughtful review.
From: Alexander Pyhalov
Sent: Monday, June 5, 2023 6:00 PM
Have found one issue -
src/backend/catalog/pg_aggregate.c
585 if(strcmp(strVal(linitial
ate itself - check it. If it's still not found, error out. Also
seems to be a bit ugly - you leave uncommitted garbage for vacuum in
catalogue.
Another issue - the patch misses recording dependency between
aggpartialfn and aggregate procedure.
--
Best regards,
Alexander Pyhalov,
Postgres Professional
fujii.y...@df.mitsubishielectric.co.jp писал 2023-06-08 02:08:
From: Alexander Pyhalov
Sent: Wednesday, June 7, 2023 6:47 PM
This seems to be more robust, but the interface became more strange.
I'm not sure what to do with it. Some ideas I had to avoid introducing
this
parameter. Not s
PostgreSQL is used,
And here.
Overall the code looks good to me, but I suppose that documentation
needs further review from some native speaker.
--
Best regards,
Alexander Pyhalov,
Postgres Professional
'm not saying we shouldn't do it - just hint at possible consequences.
--
Best regards,
Alexander Pyhalov,
Postgres Professional
; language C;
create trigger test_update after update ON test FOR EACH ROW EXECUTE
FUNCTION report_update_fields();
insert into test values (1, 12);
update test set j=2;
--
Best regards,
Alexander Pyhalov,
Postgres Professional#include
#include
#include
#include
#include
#ifdef PG_MODULE_M
py it
into
the proper long-lived context (e.g. AfterTriggerEvents).
I'll get that fixed.
Alexander, can you try if this fixes the issue for you?
regard
Hi.
The patch fixes the problem and looks good to me.
--
Best regards,
Alexander Pyhalov,
Postgres Professional
es) if we can't use cached revalidation
machinery?
I hope to get some hints to move further.
--
Best regards,
Alexander Pyhalov,
Postgres ProfessionalFrom d7cdde449daeefbfd9ccd3e72ae282f21be0c1c8 Mon Sep 17 00:00:00 2001
From: Alexander Pyhalov
Date: Fri, 23 Aug 2024 15:48:38 +0300
Sub
nd_plan() inserts sort node.
In this case mark_async_capable() can treat Sort plan node as some other
and crash, so there's a small fix for this.
--
Best regards,
Alexander Pyhalov,
Postgres ProfessionalFrom 79e40d6bcdfa96435c06d2c668efd76f3bcd5325 Mon Sep 17 00:00:00 2001
From: Alexander Pyhal
er of transactions actually processed: 14941
latency average = 6.693 ms
initial connection time = 7.037 ms
tps = 149.415688 (without initial connection time)
--
Best regards,
Alexander Pyhalov,
Postgres ProfessionalFrom 67477ab452dfc57aa9e47e4462c9f87b66911951 Mon Sep 17 00:00:00 2001
From: Alexan
Michael Paquier писал(а) 2024-10-08 05:01:
On Fri, Jul 12, 2024 at 02:39:13PM +0300, Alexander Pyhalov wrote:
I was looking at enabling partition-wise join with whole row vars. My
main
motivation
was to enable push down DML with partition-wise join in postgres_fdw.
The
work is
based on the
n RevalidateCachedQuery().
I suppose not - as we plan in executor (so shouldn't catch userid change
or see some changes in
related objects. Revalidation would kill our plan, destroying
resultDesc.
Also while looking at this, fixed processing of instead of rules (which
would lead to NULL exe
!bms_is_member(var->varno, outerrel->relids) will not execute due to
short circuit.
So I think we can remove the "!bms_is_member(var->varno,
outerrel->relids)" from if.
Any thoughts?
Hi.
Seems good to me.
--
Best regards,
Alexander Pyhalov,
Postgres Professional
array type from varchar[]
to text[].
Attaching patch to allow postgres_fdw to deparse such conversion.
--
Best regards,
Alexander Pyhalov,
Postgres ProfessionalFrom efc5eb338db6621243e25e0b0281ae69c465974d Mon Sep 17 00:00:00 2001
From: Alexander Pyhalov
Date: Wed, 27 Nov 2024 14:07:39 +0300
Subject:
Dmitry Dolgov писал(а) 2024-12-02 16:39:
On Tue, Oct 08, 2024 at 09:24:15AM GMT, Alexander Pyhalov wrote:
Attaching rebased patches.
Just to let you know, looks like CFBot tests are red again, but this
time there are some unexpected differences in some test query plan.
Hi, updated patches
Tom Lane писал(а) 2025-01-17 21:27:
Alexander Pyhalov writes:
I've rebased patch on master. Tests pass here.
The cfbot still doesn't like it; my guess is that you built without
--with-libxml and so didn't notice the effects on xml.out.
Hi. Thank you for review.
I've u
EXECUTE s(ARRAY['1','2']);
QUERY PLAN
---
Aggregate
Output: count(*)
-> Foreign Scan on public.ft_conversions
Output: id, d
Filter: (ft_conversions.d = ANY (($1)::bpchar[]))
Remote SQL: SELECT d FROM public.conversions
(6 rows)
EXECUTE s(ARRAY['1','2']);
count
---
2
--
Best regards,
Alexander Pyhalov,
Postgres Professional
Alexander Pyhalov писал(а) 2025-01-29 17:35:
Tom Lane писал(а) 2025-01-17 21:27:
Alexander Pyhalov writes:
I've rebased patch on master. Tests pass here.
The cfbot still doesn't like it; my guess is that you built without
--with-libxml and so didn't notice the effects o
Pavel Stehule писал(а) 2024-12-31 18:39:
Hi
út 31. 12. 2024 v 16:36 odesílatel Alexander Pyhalov
napsal:
Hi.
What should we do with "pre-parsed" SQL functions (when prosrc is
empty)? How should we create cached plans when we don't have raw
parsetrees?
Currently we can crea
Alexander Korotkov писал(а) 2025-03-24 11:49:
On Mon, Mar 24, 2025 at 9:07 AM Alexander Pyhalov
wrote:
Alexander Korotkov писал(а) 2025-03-24 04:21:
> Hi, Alexander!
>
> On Tue, Mar 18, 2025 at 6:04 PM Alexander Pyhalov
> wrote:
>> This shouldn't. When semi-join is foun
Alexander Korotkov писал(а) 2025-03-18 14:19:
Hi, Alexander!
On Tue, Mar 18, 2025 at 1:13 PM Alexander Pyhalov
wrote:
Alexander Korotkov писал(а) 2025-03-18 03:27:
> Hi, Robins!
>
> On Tue, Mar 18, 2025 at 2:20 AM Robins Tharakan
> wrote:
>> On Mon, 4 Dec 2023 at 07:22,
nd right join. When deparsing left/right joins and there are
semi-joins in inner or outer part of the query, the corresponding part
is deparsed as subquery. And we can't refer subquery vars from above, so
just should not pull up the restrictinfos. The attached patch does
exactly this.
--
Best re
n
pg_analyze_and_rewrite_withcb()),
but it was considered a startup error (as fcache->func_state) doesn't
exist
when error is thrown.
--
Best regards,
Alexander Pyhalov,
Postgres Professional
thoroughly.
Haven't found any issue so far. From cosmetic things I've noticed - I
would set func->pcontext to NULL in sql_delete_callback() to avoid
dangling pointer if we error out early (but it seems only to be a matter
of taste).
--
Best regards,
Alexander Pyhalov,
Postgres Professional
- instead of using index suited for filters
in where, index, suitable for sorting was selected as one having the
cheapest fractional cost.
--
Best regards,
Alexander Pyhalov,
Postgres ProfessionalFrom 268e09beb85fb5f7ce01367cdacc846ab7af471f Mon Sep 17 00:00:00 2001
From: Alexander Pyhalov
Dat
tarts
executing
(like earlier planning happened before function started executing). So,
once we
discard cached plans, plan for second query in function is not
invalidated immediately,
just on the second execution. And after rebuilding plan, it becomes
wrong.
--
Best regards,
Alexander Pyhalov,
Po
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 pathke
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
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
Hi.
Tom Lane писал(а) 2025-02-27 23:40:
Alexander Pyhalov writes:
Now sql functions plans are actually saved. The most of it is a
simplified version of plpgsql plan cache. Perhaps, I've missed
something.
A couple of thoughts about v6:
* I don't think it's okay to just su
in
for i in 1..100 loop
perform fx3((random()*100)::int);
end loop;
end;
$$;
Time: 2992.166 ms (00:02.992)
-- no plan caching due to need in fixing target list:
do $$
begin
for i in 1..100 loop
perform fx4((random()*100)::int);
end loop;
end;
$$;
Time: 11020.820 ms (00:11.021)
Time: 5346.471 ms (00:05.346)
Time: 5359.222 ms (00:05.359)
Time: 5316.747 ms (00:05.317)
New (patched) results:
Time: 5188.363 ms (00:05.188)
Time: 5225.322 ms (00:05.225)
Time: 5203.667 ms (00:05.204)
--
Best regards,
Alexander Pyhalov,
Postgres Professional
Alexander Pyhalov писал(а) 2025-03-28 15:22:
Tom Lane писал(а) 2025-03-14 23:52:
I spent some time today going through the actual code in this patch.
I realized that there's no longer any point in 0001: the later patches
don't move or repeatedly-call that bit of code, so it can be l
cution,
I don't see leaks, which were the initial reason for introducing it.
--
Best regards,
Alexander Pyhalov,
Postgres Professional
Alexander Korotkov писал(а) 2025-03-24 04:21:
Hi, Alexander!
On Tue, Mar 18, 2025 at 6:04 PM Alexander Pyhalov
wrote:
This shouldn't. When semi-join is found below left/right join, it's
deparsed as subquery.
Interesting enough, this mechanics (deparsing as subquery) is used
1) for
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
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
an issue - MyProcPort can
be not set if connection is initiated
by some bgworker. (Internally we use one for statistics collection.) In
other places (for example, in be_gssapi_get_delegation())
there are checks that port is not NULL. Likely postgres_fdw and dblink
should do something simil
lic.enum_of_int_like = character
varying
HINT: No operator matches the given name and argument types. You might
need to add explicit type casts.
--
Best regards,
Alexander Pyhalov,
Postgres Professional
Matheus Alcantara писал(а) 2025-06-25 14:36:
Hi, thanks for testing and reporting the issue!
On 25/06/25 11:37, Alexander Pyhalov wrote:
Hi.
I've started to look at this feature and found an issue - MyProcPort
can be not set if connection is initiated
by some bgworker. (Internally we us
on partitioned table without leaves. This seems
to be similar to the issue, fixed by
commit c426f7c2b36a5efd9bcef2a2dfcc559f7879cd84
Author: Michael Paquier
Date: Thu Dec 7 08:31:02 2023 +0900
Fix assertion failure with REINDEX and event triggers
Attaching rebased patch with the fix.
--
Bes
m
commit af717317a04f5217728ce296edf4a581eb7e6ea0
Author: Heikki Linnakangas
Date: Wed Mar 12 20:53:09 2025 +0200
Handle interrupts while waiting on Append's async subplans
into ExecMergeAppendAsyncEventWait().
--
Best regards,
Alexander Pyhalov,
Postgres ProfessionalFrom fe64d52c836eb1120d7446d9f1ea1ea5b
101 - 147 of 147 matches
Mail list logo
