From: Tom Lane <tgl@sss.pgh.pa.us>
To: David Rowley <dgrowleyml@gmail.com>
Cc: Sawyer Knoblich <scknoblich@gmail.com>
Cc: pgsql-bugs@lists.postgresql.org
Subject: Re: BUG #18399: Query plan optimization results in runtime error when hoisting cast from inside subquery
Date: Wed, 20 Mar 2024 00:39:05 -0400
Message-ID: <4112887.1710909545@sss.pgh.pa.us> (raw)
In-Reply-To: <CAApHDvp0717Q1dM=JDcA7YkH+ntFhDKFjX8mrR1s73q3v8yuNA@mail.gmail.com>
References: <18399-17778030a1971177@postgresql.org>
<3877106.1710863246@sss.pgh.pa.us>
<CAOfdcWBfDVsYqO=MJxS_D1uvN_woDjX6zD5+jyN=a2hC+pq4fg@mail.gmail.com>
<4085750.1710895021@sss.pgh.pa.us>
<CAOfdcWDY8Bz9OJVmNk1ESBhuCaqZQiFSWAJ36t7qwG=Q=BWRuQ@mail.gmail.com>
<CAApHDvp0717Q1dM=JDcA7YkH+ntFhDKFjX8mrR1s73q3v8yuNA@mail.gmail.com>
David Rowley <dgrowleyml@gmail.com> writes:
> There are quite a lot of things which would have to be restricted,
> much more than you might think. Any conditions which could cause an
> error would have to be evaluated last in a WHERE clause and that might
> result in being unable to use indexes because some other (possibly
> unindexed) expression would need to be evaluated first.
That particular aspect might not be too awful, because there's already
a good deal of pressure for index opclass members to not fail ---
certainly I'd expect that all standard btree comparison functions
could be marked non-failing. (Let us slide quietly past the question
of exactly how strong the guarantee should be; for example any function
that takes toastable argument types is potentially at risk of OOM,
but do you really want to exclude numeric_eq and texteq from the
set of safe operations? See also past discussions on how strict
we should be about the related concept of leakproofness.)
In any case I agree with your larger point that ordering things such
that potentially-failing tests are always done last would be a
performance disaster, even if it's possible at all.
regards, tom lane
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Reply to all the recipients using the --to and --cc options:
reply via email
To: pgsql-bugs@postgresql.org
Cc: tgl@sss.pgh.pa.us, dgrowleyml@gmail.com, scknoblich@gmail.com, pgsql-bugs@lists.postgresql.org
Subject: Re: BUG #18399: Query plan optimization results in runtime error when hoisting cast from inside subquery
In-Reply-To: <4112887.1710909545@sss.pgh.pa.us>
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
This inbox is served by DDX for PostgreSQL; see mirroring instructions
for how to clone and mirror all data and code used for this inbox