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 the
"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 K
you can play around various `enable_*` flags to see if disabling any
of these will *maybe* yield the plan you were expecting, and then
check the costs in EXPLAIN to see if the optimiser also thinks this
plan is cheaper.
On Mon, Mar 22, 2021 at 6:29 PM Chris Stephens wrote:
>
> we are but i was h
we are but i was hoping to get a better understanding of where the
optimizer is going wrong and what i can do about it.
chris
On Mon, Mar 22, 2021 at 9:54 AM Laurenz Albe
wrote:
> On Mon, 2021-03-22 at 08:10 -0500, Chris Stephens wrote:
> > The following SQL takes ~25 seconds to run. I'm relat
On Mon, 2021-03-22 at 08:10 -0500, Chris Stephens wrote:
> The following SQL takes ~25 seconds to run. I'm relatively new to postgres
> but the execution plan (https://explain.depesz.com/s/N4oR) looks like it's
> materializing the entire EXISTS subquery for each row returned by the rest
> of the
AWS RDS v12
The following SQL takes ~25 seconds to run. I'm relatively new to postgres
but the execution plan (https://explain.depesz.com/s/N4oR) looks like it's
materializing the entire EXISTS subquery for each row returned by the rest
of the query before probing for plate_384_id existence. postg
