From: | Jeff Janes <jeff(dot)janes(at)gmail(dot)com> |
---|---|
To: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
Cc: | Pavel Stehule <pavel(dot)stehule(at)gmail(dot)com>, imyfess(at)gmail(dot)com, PostgreSQL mailing lists <pgsql-bugs(at)lists(dot)postgresql(dot)org> |
Subject: | Re: BUG #16251: ::text type casting of a constant breaks query performance |
Date: | 2020-02-08 18:43:36 |
Message-ID: | CAMkU=1zcy8fX_XEQVvETD779GnMc=g_yBpftdFS_pcG9ShDGZw@mail.gmail.com |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-bugs |
On Sat, Feb 8, 2020 at 11:49 AM Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> wrote:
> Pavel Stehule <pavel(dot)stehule(at)gmail(dot)com> writes:
> > so 8. 2. 2020 v 7:44 odesílatel PG Bug reporting form <
> > noreply(at)postgresql(dot)org> napsal:
>
> If you can't rearrange things so that the IS NULL argument is seen
> as a constant, the UNION trick that Pavel mentioned might be a useful
> workaround. But I'm inclined to think that you need to take two steps
> back and figure out whether this query logic is really sane or not.
> You do realize that the query is asking to retrieve the entire table,
> if whatever-it-is is NULL? Why would that be what you want?
>
It is a pretty common tactic to do this. It much easier on the client side
to bind NULL to a parameter when you don't care, rather than dynamically
rewrite the query text to remove that condition from it. Of course that
whole thing is likely to be ANDed together with other clauses in an
unsimplified real-world example.
Cheers,
Jeff
From | Date | Subject | |
---|---|---|---|
Next Message | PG Bug reporting form | 2020-02-09 02:07:12 | BUG #16253: Documentation bug https://www.postgresql.org/docs/12/auth-methods.html |
Previous Message | Pavel Stehule | 2020-02-08 18:37:05 | Re: BUG #16252: PL/pgSQL dynamic programming not well suited for working with different schemas |