I wrote:
> After looking at this further, I think this whole "run_once"
> business is badly designed, worse documented, and redundant
> (as well as buggy). It can be replaced with three self-contained
> lines in ExecutePlan, as per the attached.
> (Obviously, the API changes in this wouldn't do f
On 12/8/24 05:23, Tomas Vondra wrote:
> On 9/18/24 04:56, shawn wang wrote:
>> Thank you very much for your response and suggestions.
>>
>> As you mentioned, the patch here is actually designed for glibc's
>> ptmalloc2 andis not applicable to other platforms. I will consider
>> supporting it onl
On 2024-12-08 15:44:23 +0700, Andrei Lepikhov wrote:
> On 8/12/2024 09:52, Andres Freund wrote:
> > > I think avoiding touching a hash table and an index under MergeJoin can
> > > also
> > > be beneficial.
> >
> > How would you get significant wins for mergejoins? You need to go through
> > both
Regarding merge joins, I suppose in some edge cases inner set scan might
not even be started.
FROM parent p
LEFT JOIN child c
ON p.id = c.id
AND p.dtype = 'B'
┌───┐ ┌───┐
parent │1,A│ │2,A│
└───┘ └───┘
^
┌───┐ ┌───┐
child │ 1 │ │ 2 │
└───┘ └───┘
On 2024-12-03 Tu 9:11 AM, Andrew Dunstan wrote:
On 2024-11-18 Mo 9:25 AM, Yan Chengpeng wrote:
Dear PostgreSQL Hackers,
*Problem Description*
I encountered an issue with the B-Tree ordering of `jsonb` values.
According to the PostgreSQL documentation[1], the ordering should
follow this p
Hi hackers!
Upgraded the "Int64 GUC" patch in order to conform to f3f06b13308e3
updates. Rebased and tested upon the current master (3f9b9621766). The
patch is still needed to be up to date as a part of the xid64 solution.
Best regards,
Evgeny Voropaev,
TantorLabs, LLC.
From 1ff7cc48d955e024
Hi hackers!
Upgraded the "Int64 GUC" patch in order to conform to f3f06b13308e3
updates. Rebased and tested upon the current master (3f9b9621766). The
patch is still needed to be up to date as a part of the xid64 solution.
Best regards,
Evgeny Voropaev,
TantorLabs, LLC.
Hi Srinath,
On Sat, 7 Dec 2024 at 11:17, Srinath Reddy Sadipiralla
wrote:
> > On Fri, 06 Dec 2024 16:40:51 +0530 Nazir Bilal Yavuz
> > wrote ---
> > LGTM.
>
> sorry i didn't get,what you meant to say is the assert failure which i said
> is correct and does my patch to this looks good?🤔
S
Hi,
I wonder if there is some hidden logic behind exposing (or not exposing)
index AM properties at SQL level?
For example, should newly added amcanbuildparallel (b437571) be
available via pg_indexam_has_property()? And also other boolean
properties like ampredlocks or amusemaintenanceworkme
On 8/12/2024 09:52, Andres Freund wrote:
I think avoiding touching a hash table and an index under MergeJoin can also
be beneficial.
How would you get significant wins for mergejoins? You need to go through both
inner and outer anyway?
In my mind, this trick can be designed for specific cases l
10 matches
Mail list logo
