Postgres Performance Date Index
[Prev Page][Next Page]
- Re: Identify root-cause for intermittent spikes
- Re: Identify root-cause for intermittent spikes
- Re: Identify root-cause for intermittent spikes
- Re: Identify root-cause for intermittent spikes
- Identify root-cause for intermittent spikes
- Re: Milions of views - performance, stability
- Milions of views - performance, stability
- Re: Query is sometimes fast and sometimes slow: what could be the reason?
- Query is sometimes fast and sometimes slow: what could be the reason?
- Faster more low-level methods of having hot standby / secondary read-only servers?
- RE: Postgresql JDBC process consumes more memory with partition tables update delete
- From: James Pang (chaolpan)
- RE: Postgresql JDBC process consumes more memory than psql client
- From: James Pang (chaolpan)
- Re: PostgresSQL 9.5.21 very slow to connect and perform basic queries
- Re: Postgresql JDBC process consumes more memory than psql client
- RE: Postgresql JDBC process consumes more memory than psql client
- From: James Pang (chaolpan)
- Re: Postgresql JDBC process consumes more memory than psql client
- RE: Postgresql JDBC process consumes more memory than psql client
- From: James Pang (chaolpan)
- Re: Postgresql JDBC process consumes more memory than psql client
- Postgresql JDBC process consumes more memory than psql client
- From: James Pang (chaolpan)
- Re: Select on partitioned table is very slow
- Re: Select on partitioned table is very slow
- Re: Select on partitioned table is very slow
- Re: Select on partitioned table is very slow
- Re: Select on partitioned table is very slow
- From: hubert depesz lubaczewski
- Select on partitioned table is very slow
- Re: pgbench: could not connect to server: Resource temporarily unavailable
- Re: pgbench: could not connect to server: Resource temporarily unavailable
- Re: pgbench: could not connect to server: Resource temporarily unavailable
- Re: pgbench: could not connect to server: Resource temporarily unavailable
- Re: pgbench: could not connect to server: Resource temporarily unavailable
- Re: pgbench: could not connect to server: Resource temporarily unavailable
- Re: pgbench: could not connect to server: Resource temporarily unavailable
- Re: pgbench: could not connect to server: Resource temporarily unavailable
- Re: pgbench: could not connect to server: Resource temporarily unavailable
- Re: pgbench: could not connect to server: Resource temporarily unavailable
- Re: pgbench: could not connect to server: Resource temporarily unavailable
- Re: pgbench: could not connect to server: Resource temporarily unavailable
- Re: pgbench: could not connect to server: Resource temporarily unavailable
- Re: pgbench: could not connect to server: Resource temporarily unavailable
- Re: pgbench: could not connect to server: Resource temporarily unavailable
- Re: pgbench: could not connect to server: Resource temporarily unavailable
- Re: pgbench: could not connect to server: Resource temporarily unavailable
- Re: pgbench: could not connect to server: Resource temporarily unavailable
- Re: pgbench: could not connect to server: Resource temporarily unavailable
- Re: pgbench: could not connect to server: Resource temporarily unavailable
- Re: pgbench: could not connect to server: Resource temporarily unavailable
- Re: pgbench: could not connect to server: Resource temporarily unavailable
- Re: pgbench: could not connect to server: Resource temporarily unavailable
- Re: pgbench: could not connect to server: Resource temporarily unavailable
- Re: pgbench: could not connect to server: Resource temporarily unavailable
- Re: pgbench: could not connect to server: Resource temporarily unavailable
- pgbench: could not connect to server: Resource temporarily unavailable
- Re: to_jsonb performance on array aggregated correlated subqueries
- Re: to_jsonb performance on array aggregated correlated subqueries
- Re: to_jsonb performance on array aggregated correlated subqueries
- Re: to_jsonb performance on array aggregated correlated subqueries
- Re: to_jsonb performance on array aggregated correlated subqueries
- Re: to_jsonb performance on array aggregated correlated subqueries
- Re: to_jsonb performance on array aggregated correlated subqueries
- Re: to_jsonb performance on array aggregated correlated subqueries
- to_jsonb performance on array aggregated correlated subqueries
- Re: Postgresql 14 partitioning advice
- Re: Postgresql 14 partitioning advice
- Re: pg_wal filling up while running huge updates
- Re: pg_wal filling up while running huge updates
- pg_wal filling up while running huge updates
- Re: PostgresSQL 9.5.21 very slow to connect and perform basic queries
- Re: PostgresSQL 9.5.21 very slow to connect and perform basic queries
- Re: Postgresql 13 partitioning advice
- Re: PgSQL 14 - Logical Rep - Single table multiple publications?
- From: Rory Campbell-Lange
- Re: PostgresSQL 9.5.21 very slow to connect and perform basic queries
- Re: PostgresSQL 9.5.21 very slow to connect and perform basic queries
- Re: PostgresSQL 9.5.21 very slow to connect and perform basic queries
- Re: PostgresSQL 9.5.21 very slow to connect and perform basic queries
- Re: PgSQL 14 - Logical Rep - Single table multiple publications?
- Re: PostgresSQL 9.5.21 very slow to connect and perform basic queries
- Re: PostgresSQL 9.5.21 very slow to connect and perform basic queries
- Re: PgSQL 14 - Logical Rep - Single table multiple publications?
- From: Rory Campbell-Lange
- PgSQL 14 - Logical Rep - Single table multiple publications?
- Re: Postgresql 14 partitioning advice
- Re: Postgresql 13 partitioning advice
- Postgresql 13 partitioning advice
- Re: Postgresql 14 partitioning advice
- Re: Postgresql 14 partitioning advice
- Re: Postgresql 14 partitioning advice
- Re: alter table xxx set unlogged take long time
- RE: alter table xxx set unlogged take long time
- From: James Pang (chaolpan)
- Re: alter table xxx set unlogged take long time
- Re: Postgresql 14 partitioning advice
- Re: alter table xxx set unlogged take long time
- Re: alter table xxx set unlogged take long time
- Re: alter table xxx set unlogged take long time
- Re: Postgresql 14 partitioning advice
- Postgresql 14 partitioning advice
- Re: alter table xxx set unlogged take long time
- RE: alter table xxx set unlogged take long time
- From: James Pang (chaolpan)
- Re: alter table xxx set unlogged take long time
- RE: alter table xxx set unlogged take long time
- From: James Pang (chaolpan)
- Re: alter table xxx set unlogged take long time
- RE: alter table xxx set unlogged take long time
- From: James Pang (chaolpan)
- Re: alter table xxx set unlogged take long time
- alter table xxx set unlogged take long time
- From: James Pang (chaolpan)
- Re: data consolidation: logical replication design considerations
- From: Rory Campbell-Lange
- Re: PostgresSQL 9.5.21 very slow to connect and perform basic queries
- Re: PostgresSQL 9.5.21 very slow to connect and perform basic queries
- Re: PostgresSQL 9.5.21 very slow to connect and perform basic queries
- Re: PostgresSQL 9.5.21 very slow to connect and perform basic queries
- Re: PostgresSQL 9.5.21 very slow to connect and perform basic queries
- Re: PostgresSQL 9.5.21 very slow to connect and perform basic queries
- Re: PostgresSQL 9.5.21 very slow to connect and perform basic queries
- PostgresSQL 9.5.21 very slow to connect and perform basic queries
- Re: data consolidation: logical replication design considerations
- From: Rory Campbell-Lange
- Re: data consolidation: logical replication design considerations
- data consolidation: logical replication design considerations
- From: Rory Campbell-Lange
- Re: Occasional performance issue after changing table partitions
- Re: Occasional performance issue after changing table partitions
- Re: Oracle_FDW table performance issue
- Re: Oracle_FDW table performance issue
- Re: Oracle_FDW table performance issue
- Re: Oracle_FDW table performance issue
- Oracle_FDW table performance issue
- functionality difference-performance postgreSQLv14-GCC-llvm-clang
- Re: Occasional performance issue after changing table partitions
- Re: Occasional performance issue after changing table partitions
- Re: Occasional performance issue after changing table partitions
- Re: Occasional performance issue after changing table partitions
- Occasional performance issue after changing table partitions
- RE: partition pruning only works for select but update
- From: James Pang (chaolpan)
- Re: partition pruning only works for select but update
- Re: partition pruning only works for select but update
- RE: partition pruning only works for select but update
- From: James Pang (chaolpan)
- Re: Fluctuating performance of updates on small table with trigger
- Fluctuating performance of updates on small table with trigger
- RE: partition pruning only works for select but update
- From: James Pang (chaolpan)
- Re: partition pruning only works for select but update
- partition pruning only works for select but update
- From: James Pang (chaolpan)
- Re: reindex option for tuning load large data
- RE: reindex option for tuning load large data
- From: James Pang (chaolpan)
- Re: reindex option for tuning load large data
- RE: reindex option for tuning load large data
- From: James Pang (chaolpan)
- Re: reindex option for tuning load large data
- reindex option for tuning load large data
- From: James Pang (chaolpan)
- Re: Missed query planner optimization: `n in (select q)` -> `n in (q)`
- Missed query planner optimization: `n in (select q)` -> `n in (q)`
- Re: Strange behavior of limit clause in complex query
- Re: Adding non-selective key to jsonb query @> reduces performance?
- Re: Strange behavior of limit clause in complex query
- Re: Strange behavior of limit clause in complex query
- Adding non-selective key to jsonb query @> reduces performance?
- Strange behavior of limit clause in complex query
- Re: Query is taking too long i intermittent
- Re: Query is taking too long i intermittent
- Re: Query is taking too long i intermittent
- Query is taking too long i intermittent
- Re: rows selectivity overestimate for @> operator for arrays
- Re: REINDEXdb performance degrading gradually PG13.4
- Re: REINDEXdb performance degrading gradually PG13.4
- Re: REINDEXdb performance degrading gradually PG13.4
- Logical reads
- REINDEXdb performance degrading gradually PG13.4
- REINDEXdb performance degrading gradually PG13.4
- RE: postgres backend process hang on " D " state
- From: James Pang (chaolpan)
- RE: postgres backend process hang on " D " state
- From: James Pang (chaolpan)
- RE: postgres backend process hang on " D " state
- From: James Pang (chaolpan)
- Re: postgres backend process hang on " D " state
- Re: postgres backend process hang on " D " state
- RE: postgres backend process hang on " D " state
- From: James Pang (chaolpan)
- Re: postgres backend process hang on " D " state
- Re: postgres backend process hang on " D " state
- postgres backend process hang on " D " state
- From: James Pang (chaolpan)
- Re: How to monitor Postgres real memory usage
- Re: rows selectivity overestimate for @> operator for arrays
- Re: How to monitor Postgres real memory usage
- rows selectivity overestimate for @> operator for arrays
- Re: How to monitor Postgres real memory usage
- Re: How to monitor Postgres real memory usage
- Re: How to monitor Postgres real memory usage
- Re: How to monitor Postgres real memory usage
- Re: How to monitor Postgres real memory usage
- Re: How to monitor Postgres real memory usage
- How to monitor Postgres real memory usage
- Re: Array of integer indexed nested-loop semi join
- From: Mickael van der Beek
- Re: Array of integer indexed nested-loop semi join
- Re: Array of integer indexed nested-loop semi join
- From: Mickael van der Beek
- Re: Array of integer indexed nested-loop semi join
- Re: Selecting RAM and CPU based on max_connections
- Re: Selecting RAM and CPU based on max_connections
- Re: Array of integer indexed nested-loop semi join
- From: Mickael van der Beek
- Re: Need help on Query Tunning and Not using the Index Scan
- Re: Selecting RAM and CPU based on max_connections
- Re: Selecting RAM and CPU based on max_connections
- Selecting RAM and CPU based on max_connections
- Need help on Query Tunning and Not using the Index Scan
- Re: DB connection issue suggestions
- Re: DB connection issue suggestions
- Re: DB connection issue suggestions
- Re: DB connection issue suggestions
- Re: DB connection issue suggestions
- Re: DB connection issue suggestions
- Re: DB connection issue suggestions
- Re: DB connection issue suggestions
- Re: DB connection issue suggestions
- Re: DB connection issue suggestions
- Re: DB connection issue suggestions
- Re: DB connection issue suggestions
- Re: DB connection issue suggestions
- DB connection issue suggestions
- Re: Why is there a Sort after an Index Only Scan?
- RE: Why is there a Sort after an Index Only Scan?
- Re: Why is there a Sort after an Index Only Scan?
- Re: Why is there a Sort after an Index Only Scan?
- Why is there a Sort after an Index Only Scan?
- Re: Window partial fetch optimization
- Re: Window partial fetch optimization
- Window partial fetch optimization
- Re: Useless memoize path generated for unique join on primary keys
- Re: Useless memoize path generated for unique join on primary keys
- Re: Useless memoize path generated for unique join on primary keys
- Useless memoize path generated for unique join on primary keys
- FATAL: canceling authentication due to timeout
- Re: LISTEN NOTIFY sometimes huge delay
- LISTEN NOTIFY sometimes huge delay
- From: Peter Eser HEUFT [Germany]
- Re: Performance differential when 0 values present vs when 1 values present. Planner return 52k rows when 0 expected.
- Re: Unworkable plan above certain row count
- Unworkable plan above certain row count
- Re: Array of integer indexed nested-loop semi join
- From: Mickael van der Beek
- Re: Array of integer indexed nested-loop semi join
- Fwd: Array of integer indexed nested-loop semi join
- From: Mickael van der Beek
- Re: Performance differential when 0 values present vs when 1 values present. Planner return 52k rows when 0 expected.
- Re: Performance differential when 0 values present vs when 1 values present. Planner return 52k rows when 0 expected.
- Re: Performance differential when 0 values present vs when 1 values present. Planner return 52k rows when 0 expected.
- Performance differential when 0 values present vs when 1 values present. Planner return 52k rows when 0 expected.
- Re: Query Planner not taking advantage of HASH PARTITION
- Re: Query Planner not taking advantage of HASH PARTITION
- Re: Postgresql TPS Bottleneck
- Re: Postgresql TPS Bottleneck
- Re: significant jump in sql statement timing for on server vs a remote connection
- Re: Postgresql TPS Bottleneck
- Re: significant jump in sql statement timing for on server vs a remote connection
- Re: Postgresql TPS Bottleneck
- Re: significant jump in sql statement timing for on server vs a remote connection
- Re: significant jump in sql statement timing for on server vs a remote connection
- significant jump in sql statement timing for on server vs a remote connection
- How to find all SQLs executed by a transaction id?
- Re: How to find the final transformed query in postgresql
- Re: How to find the final transformed query in postgresql
- How to find the final transformed query in postgresql
- Re: Query Planner not taking advantage of HASH PARTITION
- Re: Query Planner not taking advantage of HASH PARTITION
- Re: Query Planner not taking advantage of HASH PARTITION
- Re: Query Tunning related to function
- Re: Query Planner not taking advantage of HASH PARTITION
- RE: Query Tunning related to function
- RE: Query Tunning related to function
- Query Planner not taking advantage of HASH PARTITION
- Re: Query Tunning related to function
- Re: Query Tunning related to function
- Re: Performance for SQL queries on Azure PostgreSQL PaaS instance
- RE: Query Tunning related to function
- RE: Query Tunning related to function
- RE: Query Tunning related to function
- Re: SQL performance issue after migration from Oracle to Aurora postgres
- Re: Query Tunning related to function
- Query Tunning related to function
- SQL performance issue after migration from Oracle to Aurora postgres
- Re: An I/O error occurred while sending to the backend (PG 13.4)
- RE: An I/O error occurred while sending to the backend (PG 13.4)
- From: ldh@xxxxxxxxxxxxxxxxxx
- Re: Performance for SQL queries on Azure PostgreSQL PaaS instance
- RE: Performance for SQL queries on Azure PostgreSQL PaaS instance
- Re: Performance for SQL queries on Azure PostgreSQL PaaS instance
- Re: Performance for SQL queries on Azure PostgreSQL PaaS instance
- Re: Performance for SQL queries on Azure PostgreSQL PaaS instance
- Performance for SQL queries on Azure PostgreSQL PaaS instance
- Re: Slow Planning Times
- Re: Slow Planning Times
- Re: Slow Planning Times
- Re: Slow Planning Times
- Re: Slow Planning Times
- Slow Planning Times
- Re: HIGH IO and Less CPU utilization
- Re: Postgresql TPS Bottleneck
- Re: Postgresql TPS Bottleneck
- Re: Postgresql TPS Bottleneck
- Re: HIGH IO and Less CPU utilization
- Re: Postgresql TPS Bottleneck
- From: Guillaume Cottenceau
- Postgresql TPS Bottleneck
- Re: HIGH IO and Less CPU utilization
- RE: High process memory consumption when running sort
- Re: HIGH IO and Less CPU utilization
- Re: HIGH IO and Less CPU utilization
- Re: HIGH IO and Less CPU utilization
- Re: HIGH IO and Less CPU utilization
- HIGH IO and Less CPU utilization
- RE: View taking time to show records
- Re: Performance issue post upgrade on Version 13 - Incorrect Estimation Cost choosing Hash Aggregate-Nested Left Loop Join
- Re: View taking time to show records
- Re: View taking time to show records
- Re: View taking time to show records
- From: hubert depesz lubaczewski
- Re: View taking time to show records
- View taking time to show records
- Re: Performance issue post upgrade on Version 13 - Incorrect Estimation Cost choosing Hash Aggregate-Nested Left Loop Join
- Performance issue post upgrade on Version 13 - Incorrect Estimation Cost choosing Hash Aggregate-Nested Left Loop Join
- Re: Using system tables directly takes many hours, using temp tables with no indexes takes a few seconds for geometry_columns view.
- Re: High process memory consumption when running sort
- Re: Using system tables directly takes many hours, using temp tables with no indexes takes a few seconds for geometry_columns view.
- High process memory consumption when running sort
- Re: Using system tables directly takes many hours, using temp tables with no indexes takes a few seconds for geometry_columns view.
- Re: Using system tables directly takes many hours, using temp tables with no indexes takes a few seconds for geometry_columns view.
- Using system tables directly takes many hours, using temp tables with no indexes takes a few seconds for geometry_columns view.
- RE: Optimal configuration for server
- Re: Optimal configuration for server
- Re: Explain analyse with track_io_timing
- Re: Explain analyse with track_io_timing
- Explain analyse with track_io_timing
- Re: Any way to speed up INSERT INTO
- Re: Any way to speed up INSERT INTO
- Re: Any way to speed up INSERT INTO
- Re: Optimal configuration for server
- Re: Optimal configuration for server
- Re: Optimal configuration for server
- Re: Optimal configuration for server
- Re: Optimal configuration for server
- Re: Optimal configuration for server
- Re: Optimal configuration for server
- Optimal configuration for server
- Re: OOM killer while pg_restore
- Re: OOM killer while pg_restore
- Re: Any way to speed up INSERT INTO
- Re: XA transactions much slower on 14.2 than on 13.5
- XA transactions much slower on 14.2 than on 13.5
- Re: Any way to speed up INSERT INTO
- RES: Any way to speed up INSERT INTO
- Re: Any way to speed up INSERT INTO
- Re: Any way to speed up INSERT INTO
- Re: Any way to speed up INSERT INTO
- Re: Any way to speed up INSERT INTO
- Re: Any way to speed up INSERT INTO
- Any way to speed up INSERT INTO
- Re: OOM killer while pg_restore
- Re: OOM killer while pg_restore
- Re: An I/O error occurred while sending to the backend (PG 13.4)
- RE: An I/O error occurred while sending to the backend (PG 13.4)
- From: ldh@xxxxxxxxxxxxxxxxxx
- Re: An I/O error occurred while sending to the backend (PG 13.4)
- Re: An I/O error occurred while sending to the backend (PG 13.4)
- Re: An I/O error occurred while sending to the backend (PG 13.4)
- Re: OOM killer while pg_restore
- RE: An I/O error occurred while sending to the backend (PG 13.4)
- From: ldh@xxxxxxxxxxxxxxxxxx
- Re: OOM killer while pg_restore
- Re: OOM killer while pg_restore
- Re: OOM killer while pg_restore
- Re: OOM killer while pg_restore
- OOM killer while pg_restore
- Re: Simple task with partitioning which I can't realize
- Re: Simple task with partitioning which I can't realize
- RE: Simple task with partitioning which I can't realize
- Re: Advice needed: query performance deteriorates by 2000% within 1 minute
- Re: Advice needed: query performance deteriorates by 2000% within 1 minute
- Re: An I/O error occurred while sending to the backend (PG 13.4)
- Re: An I/O error occurred while sending to the backend (PG 13.4)
- RE: Simple task with partitioning which I can't realize
- Re: Simple task with partitioning which I can't realize
- RE: Simple task with partitioning which I can't realize
- Re: Simple task with partitioning which I can't realize
- RE: Simple task with partitioning which I can't realize
- Re: Simple task with partitioning which I can't realize
- RE: An I/O error occurred while sending to the backend (PG 13.4)
- From: ldh@xxxxxxxxxxxxxxxxxx
- Re: Simple task with partitioning which I can't realize
- Re: Never Ending query in PostgreSQL
- Simple task with partitioning which I can't realize
- RE: Never Ending query in PostgreSQL
- Re: Never Ending query in PostgreSQL
- RLS not using index scan but seq scan when condition gets a bit complicated
- Re: Advice needed: query performance deteriorates by 2000% within 1 minute
- Re: Never Ending query in PostgreSQL
- Re: Never Ending query in PostgreSQL
- Re: An I/O error occurred while sending to the backend (PG 13.4)
- RE: An I/O error occurred while sending to the backend (PG 13.4)
- From: ldh@xxxxxxxxxxxxxxxxxx
- RE: An I/O error occurred while sending to the backend (PG 13.4)
- From: ldh@xxxxxxxxxxxxxxxxxx
- Re: slow query to improve performace
- Re: Never Ending query in PostgreSQL
- Re: Never Ending query in PostgreSQL
- Never Ending query in PostgreSQL
- Re: slow query to improve performace
- slow query to improve performace
- RE: Slow Running Queries in Azure PostgreSQL
- Re: An I/O error occurred while sending to the backend (PG 13.4)
- Re: Slow plan choice with prepared query
- Re: Slow plan choice with prepared query
- Re: Advice needed: query performance deteriorates by 2000% within 1 minute
- Re: Advice needed: query performance deteriorates by 2000% within 1 minute
- Advice needed: query performance deteriorates by 2000% within 1 minute
- Re: An I/O error occurred while sending to the backend (PG 13.4)
- Re: An I/O error occurred while sending to the backend (PG 13.4)
- Re: An I/O error occurred while sending to the backend (PG 13.4)
- Slow plan choice with prepared query
- Re: An I/O error occurred while sending to the backend (PG 13.4)
- Re: An I/O error occurred while sending to the backend (PG 13.4)
- RE: An I/O error occurred while sending to the backend (PG 13.4)
- From: ldh@xxxxxxxxxxxxxxxxxx
- Re: Slow Running Queries in Azure PostgreSQL
- Slow Running Queries in Azure PostgreSQL
- Re: Poor performance PostgreSQL 13/ PostGIS 3.x
- Re: Query chooses Bad Index Path
- Query chooses Bad Index Path
- Re: slow "select count(*) from information_schema.tables;" in some cases
- Re: Query choosing Bad Index Path (ASC/DESC ordering).
- Query choosing Bad Index Path (ASC/DESC ordering).
- Re: slow "select count(*) from information_schema.tables;" in some cases
- Re: slow "select count(*) from information_schema.tables;" in some cases
- Re: slow "select count(*) from information_schema.tables;" in some cases
- Re: slow "select count(*) from information_schema.tables;" in some cases
- Re: slow "select count(*) from information_schema.tables;" in some cases
- Re: slow "select count(*) from information_schema.tables;" in some cases
- Re: slow "select count(*) from information_schema.tables;" in some cases
- slow "select count(*) from information_schema.tables;" in some cases
- Re: Query choosing Bad Index Path
- Query choosing Bad Index Path
- Re: Terribly slow query with very good plan?
- Re: Terribly slow query with very good plan?
- Re: Terribly slow query with very good plan?
- Re: Terribly slow query with very good plan?
- Re: Terribly slow query with very good plan?
- Re: Terribly slow query with very good plan?
- Re: Terribly slow query with very good plan?
- Re: Terribly slow query with very good plan?
- Re: Terribly slow query with very good plan?
- Re: Terribly slow query with very good plan?
- Re: Terribly slow query with very good plan?
- Re: Terribly slow query with very good plan?
- Re: Terribly slow query with very good plan?
- Re: Terribly slow query with very good plan?
- Re: Terribly slow query with very good plan?
- Re: Terribly slow query with very good plan?
- Re: Terribly slow query with very good plan?
- Re: Terribly slow query with very good plan?
- Re: Terribly slow query with very good plan?
- Re: Terribly slow query with very good plan?
- Re: Terribly slow query with very good plan?
- Terribly slow query with very good plan?
- Query runs slower as prepared statement - identical execution plans
- Re: Slow query fixed by replacing equality with a nested query
- Re: Slow query fixed by replacing equality with a nested query
- Re: Slow query fixed by replacing equality with a nested query
- RE: Slow query fixed by replacing equality with a nested query
- Re: Slow query fixed by replacing equality with a nested query
- Re: PostgreSQL and Linux CPU's
- PostgreSQL and Linux CPU's
- Poor performance PostgreSQL 13/ PostGIS 3.x
- Slow query fixed by replacing equality with a nested query
- RE: PostgreSQL 12.8 Same Query Same Execution Plan Different Time
- Re: PostgreSQL 12.8 Same Query Same Execution Plan Different Time
- PostgreSQL 12.8 Same Query Same Execution Plan Different Time
- Re: Unique constraint blues
- Unique constraint blues
- Re: PostgreSQLv14 TPC-H performance GCC vs Clang
- PGBench connection issue with -C option only
- Re: About Query Performaces Problem
- Re: About Query Performaces Problem
- Re: About Query Performaces Problem
- Re: About Query Performaces Problem
- About Query Performaces Problem
- Re: Same query 10000x More Time
- RE: Same query 10000x More Time
- Re: Same query 10000x More Time
- RE: Same query 10000x More Time
- Re: Same query 10000x More Time
- Re: Same query 10000x More Time
- Same query 10000x More Time
- Re: VACUUM: Nonremovable rows due to wal sender process
- Re:VACUUM: Nonremovable rows due to wal sender process
- VACUUM: Nonremovable rows due to wal sender process
- Re: WAL files keep piling up
- Re: 9.6 write time
- Re: 9.6 write time
- Re: 9.6 write time
- Re: 9.6 write time
- 9.6 write time
- Re: WAL files keep piling up
- Re: WAL files keep piling up
- Re: WAL files keep piling up
- Re: WAL files keep piling up
- Re: WAL files keep piling up
- WAL files keep piling up
- Re: Query is slower with a large proportion of NULLs in several columns
- Re: Query is slower with a large proportion of NULLs in several columns
- Re: Query is slower with a large proportion of NULLs in several columns
- Re: Query is slower with a large proportion of NULLs in several columns
- Re: Lock contention high
- Re: Query is slower with a large proportion of NULLs in several columns
- Re: Query is slower with a large proportion of NULLs in several columns
- Re: Query is slower with a large proportion of NULLs in several columns
- Re: Query is slower with a large proportion of NULLs in several columns
- Re: Query is slower with a large proportion of NULLs in several columns
- Re: Query is slower with a large proportion of NULLs in several columns
- Re: Query is slower with a large proportion of NULLs in several columns
- Re: Query is slower with a large proportion of NULLs in several columns
- Query is slower with a large proportion of NULLs in several columns
- PostgreSQLv14 performance client-server-HammerDB
- Re: PostgreSQLv14 TPC-H performance GCC vs Clang
- Re: pg_trgm word_similarity query does not use index for input strings longer than 8 characters
- Re: pg_trgm word_similarity query does not use index for input strings longer than 8 characters
- Re: pg_trgm word_similarity query does not use index for input strings longer than 8 characters
- pg_trgm word_similarity query does not use index for input strings longer than 8 characters
- Re: An I/O error occurred while sending to the backend (PG 13.4)
- RE: An I/O error occurred while sending to the backend (PG 13.4)
- From: ldh@xxxxxxxxxxxxxxxxxx
- Re: An I/O error occurred while sending to the backend (PG 13.4)
- An I/O error occurred while sending to the backend (PG 13.4)
- From: ldh@xxxxxxxxxxxxxxxxxx
- Re: LwLockRelease performance
- Re: LwLockRelease performance
- LwLockRelease performance
- Re: Need help identifying a periodic performance issue.
- Re: Lock contention high
- Re: pg_dump backup verification
- AW: [External] pg_dump backup verification
- pg_dump backup verification
- Re: Need help identifying a periodic performance issue.
- Re: Need help identifying a periodic performance issue.
- Re: Need help identifying a periodic performance issue.
- Re: Out of memory error
- Re: Postgres process count GCC vs Clang is Different on autovaccum=on
- Re: Out of memory error
- Re: Out of memory error
- Postgres process count GCC vs Clang is Different on autovaccum=on
- From: hpc researcher_mspk
- Re: Out of memory error
- Re: Out of memory error
- Re: Out of memory error
- Re: Out of memory error
- Re: Out of memory error
- Re: Out of memory error
- Re: Out of memory error
- Out of memory error
- Re: performance of analytical query
- Re: Need help identifying a periodic performance issue.
- Re: Need help identifying a periodic performance issue.
- Re: Need help identifying a periodic performance issue.
- Re: Need help identifying a periodic performance issue.
- Re: Need help identifying a periodic performance issue.
- Re: Need help identifying a periodic performance issue.
- Re: Need help identifying a periodic performance issue.
- Re: Need help identifying a periodic performance issue.
- Re: Need help identifying a periodic performance issue.
- Re: Need help identifying a periodic performance issue.
- Re: Need help identifying a periodic performance issue.
- Re: Need help identifying a periodic performance issue.
- Re: Need help identifying a periodic performance issue.
- Re: Need help identifying a periodic performance issue.
- Re: Need help identifying a periodic performance issue.
- Re: Need help identifying a periodic performance issue.
- Re: Need help identifying a periodic performance issue.
- Re: Lock contention high
- Re: Need help identifying a periodic performance issue.
- Re: Need help identifying a periodic performance issue.
- Re: Need help identifying a periodic performance issue.
- Re: Need help identifying a periodic performance issue.
- PostgreSQLv14 TPC-H performance GCC vs Clang
- Re: Need help identifying a periodic performance issue.
- Re: Need help identifying a periodic performance issue.
- Need help identifying a periodic performance issue.
- Re: Lock contention high
- Re: postgresql13-llvm jit-13.5-1PGDG.rhel8.x86_64
- Re: postgresql13-llvm jit-13.5-1PGDG.rhel8.x86_64
- Re: Lock contention high
- Re: postgresql13-llvm jit-13.5-1PGDG.rhel8.x86_64
- postgresql13-llvm jit-13.5-1PGDG.rhel8.x86_64
- Re: performance of analytical query
- Re: performance of analytical query
- Re: performance of analytical query
- Re: performance of analytical query
- performance of analytical query
- Re: EXISTS by itself vs SELECT EXISTS much slower in query.
- Re: EXISTS by itself vs SELECT EXISTS much slower in query.
- Re: EXISTS by itself vs SELECT EXISTS much slower in query.
- EXISTS by itself vs SELECT EXISTS much slower in query.
- Re: PostgreSQLv14 TPC-H performance GCC vs Clang
- Re: PostgreSQLv14 TPC-H performance GCC vs Clang
- JIT llvm11 package
- Re: PostgreSQLv14 TPC-H performance GCC vs Clang
- PostgreSQLv14 TPC-H performance GCC vs Clang
- Re: Lock contention high
- Re: Views don't seem to use indexes?
- Re: Views don't seem to use indexes?
- Re: Views don't seem to use indexes?
- Views don't seem to use indexes?
- Re: Lock contention high
- Re: Performance for initial copy when using pg_logical to upgrade Postgres
- Re: Lock contention high
- Re: Lock contention high
- Re: Lock contention high
- Re: Query out of memory
- Re: Lock contention high
- Re: Postgres views cannot use both union and join/where
- Re: Postgres views cannot use both union and join/where
- Re: Postgres views cannot use both union and join/where
- Re: Postgres views cannot use both union and join/where
- Re: Postgres views cannot use both union and join/where
- Re: Postgres views cannot use both union and join/where
- Postgres views cannot use both union and join/where
- From: Mithran Kulasekaran
- Re: Query out of memory
- Re: Query out of memory
- Sv: Fwd: Query out of memory
- From: Andreas Joseph Krogh
- Re: Query out of memory
- Re: Fwd: Query out of memory
- Re: Query out of memory
- Re: Query out of memory
- Fwd: Query out of memory
- Re: Lock contention high
- Re: Lock contention high
- Re: Lock contention high
- Re: Lock contention high
- Re: Lock contention high
- Re: Lock contention high
- Re: Lock contention high
- Re: Lock contention high
- Re: Lock contention high
- Re: Lock contention high
- Re: Lock contention high
- Re: Lock contention high
- Re: Lock contention high
- Re: Lock contention high
- Lock contention high
- Re: Better, consistent instrumentation for postgreSQL using a similar API as Oracle
- Re: Better, consistent instrumentation for postgreSQL using a similar API as Oracle
- Re: Better, consistent instrumentation for postgreSQL using a similar API as Oracle
- Re: Better, consistent instrumentation for postgreSQL using a similar API as Oracle
- Re: Better, consistent instrumentation for postgreSQL using a similar API as Oracle
- Re: Better, consistent instrumentation for postgreSQL using a similar API as Oracle
- Re: Better, consistent instrumentation for postgreSQL using a similar API as Oracle
- Re: Better, consistent instrumentation for postgreSQL using a similar API as Oracle
- Re: Better, consistent instrumentation for postgreSQL using a similar API as Oracle
- Re: Better, consistent instrumentation for postgreSQL using a similar API as Oracle
- Re: PG 12 slow selects from pg_settings
- Re: PG 12 slow selects from pg_settings
- Re: PG 12 slow selects from pg_settings
- Re: PG 12 slow selects from pg_settings
- PG 12 slow selects from pg_settings
- Re: Better, consistent instrumentation for postgreSQL using a similar API as Oracle
- Re: Better, consistent instrumentation for postgreSQL using a similar API as Oracle
- Re: Better, consistent instrumentation for postgreSQL using a similar API as Oracle
- Re: Better, consistent instrumentation for postgreSQL using a similar API as Oracle
- Re: Better, consistent instrumentation for postgreSQL using a similar API as Oracle
- Re: [EXT] Re: Troubleshooting a long running delete statement
- Re: [EXT] Re: Troubleshooting a long running delete statement
- Re: Troubleshooting a long running delete statement
- Re: [EXT] Re: Troubleshooting a long running delete statement
- Re: [EXT] Re: Troubleshooting a long running delete statement
- RE: [EXT] Re: Troubleshooting a long running delete statement
- RE: [EXT] Re: Troubleshooting a long running delete statement
- Re: Troubleshooting a long running delete statement
- Re: Troubleshooting a long running delete statement
- Re: Troubleshooting a long running delete statement
- Troubleshooting a long running delete statement
- Installation of PostgreSQL on fedora zVM
- Re: Better, consistent instrumentation for postgreSQL using a similar API as Oracle
- Re: Better, consistent instrumentation for postgreSQL using a similar API as Oracle
- Re: Better, consistent instrumentation for postgreSQL using a similar API as Oracle
- Re: Better, consistent instrumentation for postgreSQL using a similar API as Oracle
- Re: Better, consistent instrumentation for postgreSQL using a similar API as Oracle
- Re: Better, consistent instrumentation for postgreSQL using a similar API as Oracle
- Re: Better, consistent instrumentation for postgreSQL using a similar API as Oracle
- Re: Better, consistent instrumentation for postgreSQL using a similar API as Oracle
- Re: Better, consistent instrumentation for postgreSQL using a similar API as Oracle
- Re: Better, consistent instrumentation for postgreSQL using a similar API as Oracle
- Re: Better, consistent instrumentation for postgreSQL using a similar API as Oracle
- Re: Better, consistent instrumentation for postgreSQL using a similar API as Oracle
- From: Michaeldba@xxxxxxxxxxx
- Re: Better, consistent instrumentation for postgreSQL using a similar API as Oracle
- Re: Better, consistent instrumentation for postgreSQL using a similar API as Oracle
- Better, consistent instrumentation for postgreSQL using a similar API as Oracle
[Index of Archives]
[Postgresql General]
[Postgresql PHP]
[PHP Home]
[PHP on Windows]
[Yosemite]