Thanks for the help. In our prod environment, we shouldn't be
planning unnecessarily. Our app uses the extended query protocol
(prepare/bind/exec) to call pg/plsql stored procedures. I left out a
lot of context and background in my question, because I hoped it
simplified things. I might have left
On Tue, 21 May 2019 at 08:23, Jeremy Altavilla
wrote:
>
> Thanks for the suggestion. I created extended statistics objects for the two
> tables in question. Unfortunately the resulting plan was the same (and had
> the same estimates). It looks like the extended stats discovered a
> potentially
Thanks for the suggestion. I created extended statistics objects for the
two tables in question. Unfortunately the resulting plan was the same (and
had the same estimates). It looks like the extended stats discovered a
potentially useful correlation on bag: "2, 3 => 1" (owner_id, bag_type_id
=> id)
Jeremy Altavilla writes:
> We have several select statements whose performance is greatly improved by
> deleting some stats from pg_statistic.
You might have better results by setting up some "extended stats" for
the combination of bag_type columns that this query depends on. Per your
descriptio
Hello,
We have several select statements whose performance is greatly improved by
deleting some stats from pg_statistic. With the stats present the database
reaches 100% cpu at 13k queries per second. Without these stats, the same
machine can handle over 29k queries per second. We were able rep
