From: | Ilia Evdokimov <ilya(dot)evdokimov(at)tantorlabs(dot)com> |
---|---|
To: | Tomas Vondra <tomas(at)vondra(dot)me>, Tatsuro Yamada <yamatattsu(at)gmail(dot)com>, Masahiro(dot)Ikeda(at)nttdata(dot)com |
Cc: | 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 17:00:23 |
Message-ID: | 078283bc-a12a-474d-ba49-18289d90a422@tantorlabs.com |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
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.
>> Maybe it would be possible to walk the whole tree, and remove all the
>> RestrictInfos nodes - including intermediate ones, not just the top. But
>> I'm not quite sure it wouldn't cause issues elsewhere (assuming it
>> modifies the existing nodes). It still feels a bit like fixing a problem
>> we shouldn't really have ...
>>
> To make this idea a bit more concrete, here's a patch removing all
> RestrictInfo nodes in show_stat_qual(). But still, it feels wrong.
>
>
> regards
>
Yes, removing all 'RestrictInfos' during deparsing using
'expression_tree_mutator()' is not optimal. However, I don't see an
alternative. Perhaps it could be done this earlier in extended_stats.c
to avoid the need for cleanup later ...
--
Best regards,
Ilia Evdokimov,
Tantor Labs LLC.
From | Date | Subject | |
---|---|---|---|
Next Message | Peter Geoghegan | 2024-12-02 17:02:12 | Re: Incorrect result of bitmap heap scan. |
Previous Message | Nathan Bossart | 2024-12-02 16:58:40 | Re: Proposal for Updating CRC32C with AVX-512 Algorithm. |