Re: BUG #16251: ::text type casting of a constant breaks query performance

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

In response to

Browse pgsql-bugs by date

  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