On Thu, 11 Nov 2021 at 18:08, David Rowley wrote:
>
> On Thu, 30 Sept 2021 at 10:54, Tom Lane wrote:
> > Actually, the more I look at this the more unhappy I get, because
> > it's becoming clear that you have made unfounded semantic
> > assumptions. The hash functions generally only promise that
On Thu, 30 Sept 2021 at 10:54, Tom Lane wrote:
> Actually, the more I look at this the more unhappy I get, because
> it's becoming clear that you have made unfounded semantic
> assumptions. The hash functions generally only promise that they
> will distinguish values that are distinguishable by t
On Mon, 8 Nov 2021 at 15:38, Tom Lane wrote:
>
> David Rowley writes:
> > I've now pushed the fix to restrict v14 to only allow Memoize when the
> > left and right types are the same. For master, since it's possible to
> > add a field to RestrictInfo, I've changed that to cache the left and
> >
David Rowley writes:
> I've now pushed the fix to restrict v14 to only allow Memoize when the
> left and right types are the same. For master, since it's possible to
> add a field to RestrictInfo, I've changed that to cache the left and
> right hash equality operators.
If you were going to push
On Sat, 6 Nov 2021 at 11:38, Justin Pryzby wrote:
>
> On Tue, Oct 26, 2021 at 07:07:01PM +1300, David Rowley wrote:
> > Does anyone have any thoughts on the proposed fixes?
>
> I don't have any thoughts, but I want to be sure it isn't forgotten.
Not forgotten. I was just hoping to get some feedba
On Tue, Oct 26, 2021 at 07:07:01PM +1300, David Rowley wrote:
> Does anyone have any thoughts on the proposed fixes?
I don't have any thoughts, but I want to be sure it isn't forgotten.
--
Justin
On Thu, 30 Sept 2021 at 07:55, Jaime Casanova
wrote:
> """
> select
> 75 as c1
> from
> public.pagg_tab_ml as ref_0,
> lateral (select
> ref_0.a as c5
> from generate_series(1, 300) as sample_0
> fetch first 78 rows only
> ) as subq_0
> where case when (subq_0.c5 <
On Thu, 30 Sept 2021 at 11:54, Tom Lane wrote:
>
> David Rowley writes:
> > This allows us to memoize any join expression, not just equality
> > expressions.
>
> I am clearly failing to get through to you. Do I need to build
> an example?
Taking your -0.0 / +0.0 float example, If I understand c
David Rowley writes:
> On Thu, 30 Sept 2021 at 11:20, Tom Lane wrote:
>> Hmm ... I think that actually, a correct statement of the semantic
>> restriction is
>> To be eligible for memoization, the inside of a join can use the
>> passed-in parameters *only* as direct arguments of hashable equality
On Thu, 30 Sept 2021 at 11:20, Tom Lane wrote:
>
> I wrote:
> > So I'm now thinking you weren't that far wrong to be looking at
> > hashability of the top-level qual operator. What is missing is
> > that you have to restrict candidate cache keys to be the *direct*
> > arguments of such an operato
I wrote:
> So I'm now thinking you weren't that far wrong to be looking at
> hashability of the top-level qual operator. What is missing is
> that you have to restrict candidate cache keys to be the *direct*
> arguments of such an operator. Looking any further down in the
> expression introduces
David Rowley writes:
> On Thu, 30 Sept 2021 at 10:20, Tom Lane wrote:
>> I'm still confused. AFAICS, the top-level operator of the qual clause has
>> exactly nada to do with the cache keys, as this example makes plain.
> You're right that it does not. The lateral join condition could be
> anyth
On Thu, 30 Sept 2021 at 09:48, David Rowley wrote:
> Maybe we can cache the left and the right type's hash function and use
> the correct one in paraminfo_get_equal_hashops().
Here's a patch of what I had in mind for the fix. It's just hot off
the press, so really only intended to assist discuss
On Thu, 30 Sept 2021 at 10:20, Tom Lane wrote:
>
> David Rowley writes:
> > On Thu, 30 Sept 2021 at 10:09, Tom Lane wrote:
> >> Um ... it seems to have correctly identified the cache key expressions,
> >> so why isn't it just doing exprType on those? The jsonb_exists operator
> >> seems entirel
David Rowley writes:
> On Thu, 30 Sept 2021 at 10:09, Tom Lane wrote:
>> Um ... it seems to have correctly identified the cache key expressions,
>> so why isn't it just doing exprType on those? The jsonb_exists operator
>> seems entirely irrelevant here.
> This is down to the caching stuff I ad
On Thu, 30 Sept 2021 at 10:09, Tom Lane wrote:
>
> David Rowley writes:
> > Maybe we can cache the left and the right type's hash function and use
> > the correct one in paraminfo_get_equal_hashops().
>
> Um ... it seems to have correctly identified the cache key expressions,
> so why isn't it ju
David Rowley writes:
> On Thu, 30 Sept 2021 at 09:24, Tom Lane wrote:
>> After further inspection, "what are we doing in jsonb_hash?" is
>> indeed a relevant question, but it seems like it's a type mismatch
>> not a nullness issue. EXPLAIN VERBOSE shows
> I think you're right here. It should be
On Thu, 30 Sept 2021 at 09:24, Tom Lane wrote:
> After further inspection, "what are we doing in jsonb_hash?" is
> indeed a relevant question, but it seems like it's a type mismatch
> not a nullness issue. EXPLAIN VERBOSE shows
I think you're right here. It should be hashing text. That seems to
On 9/29/21 4:00 PM, Tom Lane wrote:
> Jaime Casanova writes:
>> I found a crash (segmentation fault) on jsonb.
>> This is the best I could do to reduce the query:
>> """
>> select
>> 75 as c1
>> from
>> public.pagg_tab_ml as ref_0,
>> lateral (select
>> ref_0.a as c5
>>
I wrote:
> I think this must be a memoize bug. AFAICS, nowhere in this query
> can we be processing a non-null JSONB value, so what are we doing
> in jsonb_hash? Something down-stack must have lost the information
> that the Datum is actually null.
After further inspection, "what are we doing in
Jaime Casanova writes:
> I found a crash (segmentation fault) on jsonb.
> This is the best I could do to reduce the query:
> """
> select
> 75 as c1
> from
> public.pagg_tab_ml as ref_0,
> lateral (select
> ref_0.a as c5
> from generate_series(1, 300) as sample_0
>
Em qua., 29 de set. de 2021 às 15:55, Jaime Casanova <
jcasa...@systemguards.com.ec> escreveu:
> Hi,
>
> I found a crash (segmentation fault) on jsonb.
> This is the best I could do to reduce the query:
>
> """
> select
> 75 as c1
> from
> public.pagg_tab_ml as ref_0,
> lateral (select
>
Hi,
I found a crash (segmentation fault) on jsonb.
This is the best I could do to reduce the query:
"""
select
75 as c1
from
public.pagg_tab_ml as ref_0,
lateral (select
ref_0.a as c5
from generate_series(1, 300) as sample_0
fetch first 78 rows only
) as subq
23 matches
Mail list logo
