Re: SELECT performance drop

On Tue, Jan 22, 2019 at 2:55 PM legrand legrand wrote: > Hello, > could you check that statistics for fm_session are accurate ? > > Regards > PAscal > heroku pg:psql -c "SELECT schemaname, relname, last_analyze FROM pg_stat_all_tables WHERE relname LIKE 'fm_%'" schemaname |relname | last

Re: SELECT performance drop

Hello, could you check that statistics for fm_session are accurate ? Regards PAscal -- Sent from: http://www.postgresql-archive.org/PostgreSQL-performance-f2050081.html

Re: SELECT performance drop

On Tue, Jan 22, 2019 at 1:04 PM Jan Nielsen wrote: > I just notice that one of my Hibernate JPA SELECTs against my Heroku PG > 10.4 instance is taking a l o o o g to complete > as this EXPLAIN (ANALYZE, BUFFERS) > shows. The database is 591MB running in PG 10

SELECT performance drop

I just notice that one of my Hibernate JPA SELECTs against my Heroku PG 10.4 instance is taking a l o o o g to complete as this EXPLAIN (ANALYZE, BUFFERS) shows. The database is 591MB running in PG 10.4 on Heroku with the following row counts and index use:

RE: Memory and hard ware calculation :

Hi, My question Our connection is 1100 parallel connection and 1 GB I/p data and 1 GB o/p data in each connection, currently we are using 64 GB RAM and 8 core. But we need all the reports below 3 seconds. So kindly suggest expanding my hard ware and work memory. Is there any possibility to get

Re: Very long query planning times for database with lots of partitions

Thank both of you for your quick answers, @Justin Based on your answer it would seem to confirm that partitioning or at least partitioning this much is not the correct direction to take. The reason I originally wanted to use partitioning was that I'm storing a multi-tenant graph and that as the da

RE: Very long query planning times for database with lots of partitions

Do you have constraint_exclusion set correctly (i.e. ‘on’ or ‘partition’)? If so, does the EXPLAIN output mention all of your parent partitions, or are some being successfully pruned? Planning times can be sped up significantly if the planner can exclude parent partitions, without ever having to

Re: Very long query planning times for database with lots of partitions

On Tue, Jan 22, 2019 at 02:44:29PM +0100, Mickael van der Beek wrote: > Hey everyone, > > I have a PostgreSQL 10 database that contains two tables which both have > two levels of partitioning (by list and using a single value). Meaning that > a partitioned table gets repartitioned again. > > The

Very long query planning times for database with lots of partitions

Hey everyone, I have a PostgreSQL 10 database that contains two tables which both have two levels of partitioning (by list and using a single value). Meaning that a partitioned table gets repartitioned again. The data in my use case is stored on 5K to 10K partitioned tables (children and grand-ch

Re: Memory and hard ware calculation :

Hi, As per '1100 concurrent connections' I think you want to have a close look to your CPU. It looks to me a lot of connections, much more than what 8 cores can handle and you will probably end up in a situation where your CPU spends a lot of time in handling the connections rather than serving t