Here is a commit that accomplishes this with a configuration parameter.
https://github.com/labkey-matthewb/postgres/commit/b1fd99f4deffbbf3db2172ccaba51a34f18d1b1a
On Mon, Sep 28, 2020 at 2:07 PM Tom Lane wrote:
> Timothy Garnett writes:
> > Is there some way to tell the planner that unless it
Timothy Garnett writes:
> Is there some way to tell the planner that unless it's guaranteed by a
> constraint or some such it shouldn't guess that the selectivity of a
> filter/anti-join is 1 row (e.g. minimum to consider is 2 rows unless it's
> guaranteed to be 1 row) or somehow otherwise make it
Is there some way to tell the planner that unless it's guaranteed by a
constraint or some such it shouldn't guess that the selectivity of a
filter/anti-join is 1 row (e.g. minimum to consider is 2 rows unless it's
guaranteed to be 1 row) or somehow otherwise make it more conservative
around the wor
We faced a similar issue, adding RDS proxy in front of RDS Postgres can
help.
In our situation, there were a lot of connects/disconnects from Lambda
functions although concurrency of Lambda was 100 only.
And adding connection pooler(RDS proxy) helped us to reduce the CPU load
from 100% to 30%
Happ
>
>
> Hi,
> We have an application where one of the APIs calling queries(attached) is
> spiking the CPU to 100% during load testing.
> However, queries are making use of indexes(Bitmap Index and Bitmap Heap
> scan though). When run separately on DB queries hardly take less than 200
> ms. Is CPU spi
