When I do serious database development I try to use database functions
as much as possible.
You can attach any flag value to a function in which case it gets set
when the function is running,
In your case you could probably wrap your query into an set-returning
`LANGUAGE SQL` function [1] and
On Wed, 24 Mar 2021 at 00:07, Rick Otten wrote:
>
>> Yes, the columns are highly correlated, but that alone doesn't seem like
>> it should be sufficient criteria to choose this plan.
>> Ie the selection criteria (1 day of data about a year ago) has a year+
>> worth of data after it and probably
"set enable_material=false;" produces an efficient plan. good to know there
are *some* knobs to turn when the optimizer comes up with a bad plan. would
be awesome if you could lock that plan into place w/out altering the
variable.
thanks for the help Hannu!
On Mon, Mar 22, 2021 at 4:39 PM Hannu
On Tue, Mar 23, 2021 at 2:52 AM Paul McGarry wrote:
>
>
> On Tue, 23 Mar 2021 at 16:13, Justin Pryzby wrote:
>
>> On Tue, Mar 23, 2021 at 03:00:38PM +1100, Paul McGarry wrote:
>> > I have a query where Postgresql (11.9 at the moment) is making an odd
>> plan
>> > choice, choosing to use index
On Tue, 23 Mar 2021 at 16:13, Justin Pryzby wrote:
> On Tue, Mar 23, 2021 at 03:00:38PM +1100, Paul McGarry wrote:
> > I have a query where Postgresql (11.9 at the moment) is making an odd
> plan
> > choice, choosing to use index scans which require filtering out millions
> of
> > rows, rather
