From: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
---|---|
To: | Ilia Evdokimov <ilya(dot)evdokimov(at)tantorlabs(dot)com> |
Cc: | Tomas Vondra <tomas(at)vondra(dot)me>, Tatsuro Yamada <yamatattsu(at)gmail(dot)com>, Masahiro(dot)Ikeda(at)nttdata(dot)com, tomas(dot)vondra(at)enterprisedb(dot)com, tatsuro(dot)yamada(at)ntt(dot)com, pgsql-hackers(at)postgresql(dot)org, Masao(dot)Fujii(at)nttdata(dot)com |
Subject: | Re: Showing applied extended statistics in explain Part 2 |
Date: | 2024-12-02 23:05:16 |
Message-ID: | 1691487.1733180716@sss.pgh.pa.us |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
Ilia Evdokimov <ilya(dot)evdokimov(at)tantorlabs(dot)com> writes:
> On 19.11.2024 00:38, Tomas Vondra wrote:
>> On 11/18/24 22:15, Tomas Vondra wrote:
>>> So I think the correct solution is to not pass any expressions with
>>> RestrictInfo to deparse_expression(). Either by stripping the nodes, or
>>> by not adding them at all.
>>>
>>> The patch tries to do the stripping by maybe_extract_actual_clauses(),
>>> but that only looks at the top node, and that is not sufficient here.
Pardon me for being late to the party, but I don't understand why this
is difficult. There should never be more than one layer of
RestrictInfos, at the top level of an implicitly-ANDed list of quals.
The only exception to this is that RestrictInfos representing OR
clauses have an additional field "orclause" that attaches
RestrictInfos to the elements of the OR list --- but the main "clause"
field doesn't look like that, and you can just ignore "orclause" if it
doesn't suit you. So ISTM this doesn't need to be any harder than
what extract_actual_clauses() does (and has done for decades).
regards, tom lane
From | Date | Subject | |
---|---|---|---|
Next Message | Thomas Munro | 2024-12-02 23:21:33 | Re: Remove useless casts to (void *) |
Previous Message | Andres Freund | 2024-12-02 22:48:23 | Re: Remove useless casts to (void *) |