On Sun, Mar 22, 2020 at 11:45:53PM -0400, Ronnie S wrote:
> Hello All,
>
> While doing some tests with hash partitioning behavior in PG11 and 12, I
> have found that PG11 is not performing partition pruning with DELETEs
> (explain analyze returned >2000 lines). I then ran the same test in PG12
> a
Hello All,
While doing some tests with hash partitioning behavior in PG11 and 12, I
have found that PG11 is not performing partition pruning with DELETEs
(explain analyze returned >2000 lines). I then ran the same test in PG12
and recreated the objects using the same DDL, and it worked
Here are t
On Sun, Mar 22, 2020 at 09:22:50PM -0400, Arya F wrote:
> I have noticed that my write/update performance starts to dramatically
> reduce after about 10 million rows on my hardware. The reason for the
> slowdown is the index updates on every write/update.
It's commonly true that the indexes need t
I have noticed that my write/update performance starts to dramatically
reduce after about 10 million rows on my hardware. The reason for the
slowdown is the index updates on every write/update.
The solution would be partitioning? One of my tables will have more
than 1 billion rows of data, so I wo
Are you able to tweak the query or is that generated by an ORM? What
version of Postgres? Which configs have you changed from default? How many
partitions do you have? Is there an index on company name?
Anytime I see distinct keyword, I expect it to be a performance bottleneck
and wonder about rew
Hi folks,
We are using postgreSQL database and I am hitting some limits. I have
partitions on company_sale_account table
based on company name
We generate a report on accounts matched between the two. Below is the
query:
SELECT DISTINCT cpsa1.*
FROM company_sale_account cpsa1
JOIN company_sale
