pgsql-performance  

Messages by Thread

• Max write throughput for single COPY Joe Wildish
• How to analyze of short but heavy intermittent slowdown on BIND on production database (or BIND vs log_lock_waits) Maxim Boguk
  • Re: How to analyze of short but heavy intermittent slowdown on BIND on production database (or BIND vs log_lock_waits) Justin Pryzby
  • Re: How to analyze of short but heavy intermittent slowdown on BIND on production database (or BIND vs log_lock_waits) Maxim Boguk
  • Re: How to analyze of short but heavy intermittent slowdown on BIND on production database (or BIND vs log_lock_waits) MichaelDBA
  • Re: How to analyze of short but heavy intermittent slowdown on BIND on production database (or BIND vs log_lock_waits) Maxim Boguk
  • Re: How to analyze of short but heavy intermittent slowdown on BIND on production database (or BIND vs log_lock_waits) MichaelDBA
  • Re: How to analyze of short but heavy intermittent slowdown on BIND on production database (or BIND vs log_lock_waits) Maxim Boguk
  • Re: How to analyze of short but heavy intermittent slowdown on BIND on production database (or BIND vs log_lock_waits) MichaelDBA
  • Re: How to analyze of short but heavy intermittent slowdown on BIND on production database (or BIND vs log_lock_waits) Maxim Boguk
  • Re: How to analyze of short but heavy intermittent slowdown on BIND on production database (or BIND vs log_lock_waits) Maxim Boguk
  • Re: How to analyze of short but heavy intermittent slowdown on BIND on production database (or BIND vs log_lock_waits) MichaelDBA
  • Re: How to analyze of short but heavy intermittent slowdown on BIND on production database (or BIND vs log_lock_waits) Maxim Boguk
  • Re: How to analyze of short but heavy intermittent slowdown on BIND on production database (or BIND vs log_lock_waits) MichaelDBA
• When you really want to force a certain join type? Gunther Schadow
  • Re: When you really want to force a certain join type? Justin Pryzby
  • Re: When you really want to force a certain join type? Gunther Schadow
  • Re: When you really want to force a certain join type? Tom Lane
• temp_file_limit? Frits Jalvingh
  • Re: temp_file_limit? Justin Pryzby
  • Fwd: temp_file_limit? Frits Jalvingh
  • Re: Fwd: temp_file_limit? Tom Lane
  • Re: Fwd: temp_file_limit? Justin Pryzby
  • Re: Fwd: temp_file_limit? Thomas Munro
  • Re: Fwd: temp_file_limit? Thomas Munro
  • Re: Fwd: temp_file_limit? Frits Jalvingh
  • Re: Fwd: temp_file_limit? Ranier Vilela
  • Re: Fwd: temp_file_limit? Frits Jalvingh
  • Re: Fwd: temp_file_limit? Ranier Vilela
  • Re: Fwd: temp_file_limit? Frits Jalvingh
  • Re: Fwd: temp_file_limit? Justin Pryzby
  • Re: Fwd: temp_file_limit? Frits Jalvingh
  • Re: Fwd: temp_file_limit? Ranier Vilela
  • Re: Fwd: temp_file_limit? Frits Jalvingh
  • Re: Fwd: temp_file_limit? Thomas Munro
  • Re: Fwd: temp_file_limit? Frits Jalvingh
  • Re: Fwd: temp_file_limit? Frits Jalvingh
  • Re: Fwd: temp_file_limit? Justin Pryzby
  • Re: Fwd: temp_file_limit? Justin Pryzby
  • Re: Fwd: temp_file_limit? Frits Jalvingh
  • Re: Fwd: temp_file_limit? Justin Pryzby
  • Re: Fwd: temp_file_limit? Frits Jalvingh
• Postgres12 looking for possible HashAggregate issue workarounds? João Paulo Luís
  • Re: Postgres12 looking for possible HashAggregate issue workarounds? Justin Pryzby
  • RE: Postgres12 looking for possible HashAggregate issue workarounds? João Paulo Luís
  • Re: Postgres12 looking for possible HashAggregate issue workarounds? David Rowley
  • RE: Postgres12 looking for possible HashAggregate issue workarounds? João Paulo Luís
• JSON down performacen when id:1 Render Comunicacion S . L .
  • Re: JSON down performacen when id:1 Tom Lane
  • Re: JSON down performacen when id:1 Render Comunicacion S.L.
• time sorted UUIDs Tim Jones
  • Re: time sorted UUIDs Laurenz Albe
  • Re: time sorted UUIDs Adrien Nayrat
  • Re: time sorted UUIDs peter plachta
• DML sql execution time slow down PGv14 compared with PGv13 James Pang (chaolpan)
  • Re: DML sql execution time slow down PGv14 compared with PGv13 David Rowley
  • RE: DML sql execution time slow down PGv14 compared with PGv13 James Pang (chaolpan)
  • RE: DML sql execution time slow down PGv14 compared with PGv13 James Pang (chaolpan)
  • DML sql execution time slow down PGv14 compared with PGv13 James Pang (chaolpan)
  • Re: DML sql execution time slow down PGv14 compared with PGv13 Samed YILDIRIM
  • RE: DML sql execution time slow down PGv14 compared with PGv13 James Pang (chaolpan)
  • RE: DML sql execution time slow down PGv14 compared with PGv13 James Pang (chaolpan)
• creating hash indexes Rick Otten
  • Re: creating hash indexes Peter Geoghegan
• Re: Increased iowait and blk_read_time with higher shared_buffers Samed YILDIRIM
  • Re: Increased iowait and blk_read_time with higher shared_buffers Jordan Hurwich
  • Re: Increased iowait and blk_read_time with higher shared_buffers Tom Lane
  • Re: Increased iowait and blk_read_time with higher shared_buffers Jordan Hurwich
  • Re: Increased iowait and blk_read_time with higher shared_buffers Samed YILDIRIM
  • Re: Increased iowait and blk_read_time with higher shared_buffers Jordan Hurwich
• wrong rows and cost estimation when generic plan James Pang
  • RE: wrong rows and cost estimation when generic plan James Pang (chaolpan)
  • Re: wrong rows and cost estimation when generic plan David Rowley
  • RE: wrong rows and cost estimation when generic plan James Pang (chaolpan)
  • Re: wrong rows and cost estimation when generic plan David Rowley
  • RE: wrong rows and cost estimation when generic plan James Pang (chaolpan)
• Odd Choice of seq scan Paul McGarry
  • Re: Odd Choice of seq scan Justin Pryzby
  • Re: Odd Choice of seq scan Ronuk Raval
  • Re: Odd Choice of seq scan Tom Lane
  • Re: Odd Choice of seq scan Paul McGarry
  • Re: Odd Choice of seq scan Chris Hoover
• Geometric types row estimation Igor ALBUQUERQUE SILVA
  • Re: Geometric types row estimation Igor ALBUQUERQUE SILVA
  • Re: Geometric types row estimation Tom Lane
  • Re: Geometric types row estimation Igor ALBUQUERQUE SILVA
  • Re: Geometric types row estimation Tom Lane
  • Re: Geometric types row estimation Igor ALBUQUERQUE SILVA
• Catching up with performance & PostgreSQL 15 Josh Berkus
  • Re: Catching up with performance & PostgreSQL 15 Justin Pryzby
  • Re: Catching up with performance & PostgreSQL 15 Josh Berkus
  • Re: Catching up with performance & PostgreSQL 15 Mladen Gogala
  • Re: Catching up with performance & PostgreSQL 15 Alvaro Herrera
  • Re: Catching up with performance & PostgreSQL 15 Mladen Gogala
  • Re: Catching up with performance & PostgreSQL 15 Alvaro Herrera
  • Re: Catching up with performance & PostgreSQL 15 Mladen Gogala
  • Re: Catching up with performance & PostgreSQL 15 Alvaro Herrera
  • Re: Catching up with performance & PostgreSQL 15 Mladen Gogala
  • Re: Catching up with performance & PostgreSQL 15 Tom Lane
  • Re: Catching up with performance & PostgreSQL 15 David Rowley
  • Re: Catching up with performance & PostgreSQL 15 Andrew Dunstan
  • Re: Catching up with performance & PostgreSQL 15 Andres Freund
  • Re: Catching up with performance & PostgreSQL 15 Tom Lane
  • Re: Catching up with performance & PostgreSQL 15 Andrew Dunstan
  • Re: Catching up with performance & PostgreSQL 15 Jeff Janes
• Need suggestion to set-up RDS alerts on GP3 volumes Sengottaiyan T
• why choosing an hash index instead of the btree version even if the cost is lower? Luca Ferrari
  • Re: why choosing an hash index instead of the btree version even if the cost is lower? Tomas Vondra
  • Re: why choosing an hash index instead of the btree version even if the cost is lower? Tom Lane
  • Re: why choosing an hash index instead of the btree version even if the cost is lower? Luca Ferrari
  • Re: why choosing an hash index instead of the btree version even if the cost is lower? Luca Ferrari
• When can joins be avoided? Stefan Fehrenbach
  • Re: When can joins be avoided? Tom Lane
• =ANY(ARRAY) vs =ANY(ARRAY(expr)) performance Ramdip Gill
  • Re: =ANY(ARRAY) vs =ANY(ARRAY(expr)) performance Ramdip Gill
  • Re: =ANY(ARRAY) vs =ANY(ARRAY(expr)) performance Rick Otten
  • Re: =ANY(ARRAY) vs =ANY(ARRAY(expr)) performance Guillaume Cottenceau
• ogr2ogr slow sql when checking system tables for column info and so on. Lars Aksel Opsahl
  • Re: ogr2ogr slow sql when checking system tables for column info and so on. Julien Rouhaud
  • Re: ogr2ogr slow sql when checking system tables for column info and so on. Lars Aksel Opsahl
  • Re: ogr2ogr slow sql when checking system tables for column info and so on. Julien Rouhaud
  • Re: ogr2ogr slow sql when checking system tables for column info and so on. Lars Aksel Opsahl
• Explain returns different number of rows Vince McMahon
• Identify root-cause for intermittent spikes Sengottaiyan T
  • Re: Identify root-cause for intermittent spikes MichaelDBA
  • Re: Identify root-cause for intermittent spikes Sengottaiyan T
  • Re: Identify root-cause for intermittent spikes hubert depesz lubaczewski
  • Re: Identify root-cause for intermittent spikes Sengottaiyan T
  • Re: Identify root-cause for intermittent spikes Julien Rouhaud
  • Re: Identify root-cause for intermittent spikes hubert depesz lubaczewski
  • Re: Identify root-cause for intermittent spikes Rick Otten
  • Re: Identify root-cause for intermittent spikes Sengottaiyan T
  • Re: Identify root-cause for intermittent spikes SAMEER KUMAR
• Milions of views - performance, stability Hubert Rutkowski
  • Re: Milions of views - performance, stability Laurenz Albe
• Query is sometimes fast and sometimes slow: what could be the reason? tiaswin
  • Re: Query is sometimes fast and sometimes slow: what could be the reason? Justin Pryzby
• Faster more low-level methods of having hot standby / secondary read-only servers? Gunther Schadow
• Postgresql JDBC process consumes more memory than psql client James Pang (chaolpan)
  • Re: Postgresql JDBC process consumes more memory than psql client Justin Pryzby
  • RE: Postgresql JDBC process consumes more memory than psql client James Pang (chaolpan)
  • Re: Postgresql JDBC process consumes more memory than psql client Justin Pryzby
  • RE: Postgresql JDBC process consumes more memory than psql client James Pang (chaolpan)
  • Re: Postgresql JDBC process consumes more memory than psql client Justin Pryzby
  • RE: Postgresql JDBC process consumes more memory than psql client James Pang (chaolpan)
  • RE: Postgresql JDBC process consumes more memory with partition tables update delete James Pang (chaolpan)
• Select on partitioned table is very slow Jose Osinde
  • Re: Select on partitioned table is very slow hubert depesz lubaczewski
  • Re: Select on partitioned table is very slow Laurenz Albe
  • Re: Select on partitioned table is very slow Jose Osinde
  • Re: Select on partitioned table is very slow Ranier Vilela
  • Re: Select on partitioned table is very slow Jose Osinde
• pgbench: could not connect to server: Resource temporarily unavailable Kevin McKibbin
  • Re: pgbench: could not connect to server: Resource temporarily unavailable Tom Lane
  • Re: pgbench: could not connect to server: Resource temporarily unavailable Kevin McKibbin
  • Re: pgbench: could not connect to server: Resource temporarily unavailable Andrew Dunstan
  • Re: pgbench: could not connect to server: Resource temporarily unavailable Tom Lane
  • Re: pgbench: could not connect to server: Resource temporarily unavailable Andrew Dunstan
  • Re: pgbench: could not connect to server: Resource temporarily unavailable Tom Lane
  • Re: pgbench: could not connect to server: Resource temporarily unavailable Thomas Munro
  • Re: pgbench: could not connect to server: Resource temporarily unavailable Tom Lane
  • Re: pgbench: could not connect to server: Resource temporarily unavailable Thomas Munro
  • Re: pgbench: could not connect to server: Resource temporarily unavailable Tom Lane
  • Re: pgbench: could not connect to server: Resource temporarily unavailable Thomas Munro
  • Re: pgbench: could not connect to server: Resource temporarily unavailable Tom Lane
  • Re: pgbench: could not connect to server: Resource temporarily unavailable Thomas Munro
  • Re: pgbench: could not connect to server: Resource temporarily unavailable Tom Lane
  • Re: pgbench: could not connect to server: Resource temporarily unavailable Tom Lane
  • Re: pgbench: could not connect to server: Resource temporarily unavailable Thomas Munro
  • Re: pgbench: could not connect to server: Resource temporarily unavailable Tom Lane
  • Re: pgbench: could not connect to server: Resource temporarily unavailable Thomas Munro
  • Re: pgbench: could not connect to server: Resource temporarily unavailable Thomas Munro
  • Re: pgbench: could not connect to server: Resource temporarily unavailable Tom Lane
  • Re: pgbench: could not connect to server: Resource temporarily unavailable Thomas Munro
  • Re: pgbench: could not connect to server: Resource temporarily unavailable Junwang Zhao
  • Re: pgbench: could not connect to server: Resource temporarily unavailable Tom Lane
  • Re: pgbench: could not connect to server: Resource temporarily unavailable Junwang Zhao
  • Re: pgbench: could not connect to server: Resource temporarily unavailable Kevin McKibbin
  • Re: pgbench: could not connect to server: Resource temporarily unavailable Andres Freund
• to_jsonb performance on array aggregated correlated subqueries Nico Heller
  • Re: to_jsonb performance on array aggregated correlated subqueries Justin Pryzby
  • Re: to_jsonb performance on array aggregated correlated subqueries Nico Heller
  • Re: to_jsonb performance on array aggregated correlated subqueries Justin Pryzby
  • Re: to_jsonb performance on array aggregated correlated subqueries Nico Heller
  • Re: to_jsonb performance on array aggregated correlated subqueries Nico Heller
  • Re: to_jsonb performance on array aggregated correlated subqueries Andres Freund
  • Re: to_jsonb performance on array aggregated correlated subqueries Nico Heller
  • Re: to_jsonb performance on array aggregated correlated subqueries Rick Otten
• pg_wal filling up while running huge updates aditya desai
  • Re: pg_wal filling up while running huge updates Don Seiler
  • Re: pg_wal filling up while running huge updates Justin Pryzby
• Re: PgSQL 14 - Logical Rep - Single table multiple publications? Rory Campbell-Lange
  • Re: PgSQL 14 - Logical Rep - Single table multiple publications? Rory Campbell-Lange
• Postgresql 13 partitioning advice Ameya Bidwalkar
  • Re: Postgresql 13 partitioning advice David Rowley
  • Re: Postgresql 13 partitioning advice Ameya Bidwalkar
• Postgresql 14 partitioning advice Rick Otten
  • Re: Postgresql 14 partitioning advice Justin Pryzby
  • Re: Postgresql 14 partitioning advice Jeff Janes
  • Re: Postgresql 14 partitioning advice Rick Otten

• Earlier messages
• Later messages