| From: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
|---|---|
| To: | David Rowley <dgrowleyml(at)gmail(dot)com> |
| Cc: | David Rowley <drowley(at)postgresql(dot)org>, Jaime Casanova <jcasanov(at)systemguards(dot)com(dot)ec>, PostgreSQL-development <pgsql-hackers(at)postgresql(dot)org> |
| Subject: | Re: jsonb crash |
| Date: | 2021-09-29 21:20:09 |
| Message-ID: | 3002519.1632950409@sss.pgh.pa.us |
| Views: | Raw Message | Whole Thread | Download mbox | Resend email |
| Thread: | |
| Lists: | pgsql-hackers |
David Rowley <dgrowleyml(at)gmail(dot)com> writes:
> On Thu, 30 Sept 2021 at 10:09, Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> 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 added to RestrictInfo to minimise
> the amount of work done during the join search. I cached the hash
> equal function in RestrictInfo so I didn't have to check what that was
> each time we consider a join. The problem is, that I did a bad job of
> taking inspiration from check_hashjoinable() which just looks at the
> left type.
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.
regards, tom lane
| From | Date | Subject | |
|---|---|---|---|
| Next Message | Alvaro Herrera | 2021-09-29 21:27:54 | Re: prevent immature WAL streaming |
| Previous Message | David Rowley | 2021-09-29 21:17:19 | Re: jsonb crash |