Postgres Performance Date Index

• Thread Index

• Re: Should from_collapse be switched off? (queries 10 times faster)
  • From: Peter
• Re: Slow planning time for custom function
  • From: bk
• Re: functions: VOLATILE performs better than STABLE
  • From: David Rowley
• Re: Should from_collapse be switched off? (queries 10 times faster)
  • From: Laurenz Albe
• Re: functions: VOLATILE performs better than STABLE
  • From: Laurenz Albe
• functions: VOLATILE performs better than STABLE
  • From: Peter
• Re: Slow planning time for custom function
  • From: David Rowley
• Re: Slow planning time for custom function
  • From: Andres Freund
• Slow planning time for custom function
  • From: bk
• Re: Should from_collapse be switched off? (queries 10 times faster)
  • From: Peter
• Re: DB corruption
  • From: Tom Lane
• Re: Should from_collapse be switched off? (queries 10 times faster)
  • From: Peter
• Re: Should from_collapse be switched off? (queries 10 times faster)
  • From: Peter
• Re: Should from_collapse be switched off? (queries 10 times faster)
  • From: Tom Lane
• Re: Should from_collapse be switched off? (queries 10 times faster)
  • From: Laurenz Albe
• Re: Should from_collapse be switched off? (queries 10 times faster)
  • From: Thomas Kellerer
• Should from_collapse be switched off? (queries 10 times faster)
  • From: Peter
• Re: DB corruption
  • From: Michael Paquier
• DB corruption
  • From: Akshay Ballarpure
• Re: badly scaling performance with appending to bytea
  • From: Pavel Stehule
• Re: badly scaling performance with appending to bytea
  • From: Gary Cowell
• Re: badly scaling performance with appending to bytea
  • From: Pavel Stehule
• Re: badly scaling performance with appending to bytea
  • From: Pavel Stehule
• Re: badly scaling performance with appending to bytea
  • From: Rick Otten
• badly scaling performance with appending to bytea
  • From: Gary Cowell
• RE: PG 9.6 Slow inserts with long-lasting LWLocks
  • From: Pavel Suderevsky
• Re: Slow performance after restoring a dump
  • From: David Osborne
• Re: Slow performance after restoring a dump
  • From: Tom Lane
• Re: Slow performance after restoring a dump
  • From: David Osborne
• Re: Slow performance after restoring a dump
  • From: Tom Lane
• Slow performance after restoring a dump
  • From: David Osborne
• Re: Irrelevant columns cause massive performance change
  • From: Craig James
• Re: Irrelevant columns cause massive performance change
  • From: Andres Freund
• Irrelevant columns cause massive performance change
  • From: Craig James
• Re: PG 9.6 Slow inserts with long-lasting LWLocks
  • From: MichaelDBA
• RE: PG 9.6 Slow inserts with long-lasting LWLocks
  • From: Pavel Suderevsky
• Re: Too many .history file in pg_xlog takes lots of space
  • From: 彭昱傑
• Re: Too many .history file in pg_xlog takes lots of space
  • From: Tom Lane
• Re: Too many .history file in pg_xlog takes lots of space
  • From: Alvaro Herrera
• Re: Too many .history file in pg_xlog takes lots of space
  • From: Michael Paquier
• Re: Too many .history file in pg_xlog takes lots of space
  • From: 彭昱傑
• Re: Too many .history file in pg_xlog takes lots of space
  • From: Laurenz Albe
• Too many .history file in pg_xlog takes lots of space
  • From: 彭昱傑
• Re: Memory size
  • From: dangal
• Re: Memory size
  • From: dangal
• Re: Memory size
  • From: Jeff Janes
• Sv: Re: Sv: Memory size
  • From: Andreas Joseph Krogh
• Re: Memory size
  • From: dangal
• Re: Memory size
  • From: Tomas Vondra
• Re: Memory size
  • From: dangal
• Re: Memory size
  • From: Jeff Janes
• Re: Sv: Memory size
  • From: dangal
• Sv: Memory size
  • From: Andreas Joseph Krogh
• Memory size
  • From: dangal
• RE: Updating large tables without dead tuples
  • From: ldh@xxxxxxxxxxxxxxxxxx
• Re: by mistake dropped physical file dropped for one table.
  • From: Rambabu V
• Re: need meta data table/command to find query log
  • From: Stephen Frost
• Re: by mistake dropped physical file dropped for one table.
  • From: Stephen Frost
• Re: Please help
  • From: Tomas Vondra
• need meta data table/command to find query log
  • From: Rambabu V
• by mistake dropped physical file dropped for one table.
  • From: Rambabu V
• Re: GIST index (polygon, point)
  • From: Laurenz Albe
• Please help
  • From: Daulat Ram
• GIST index (polygon, point)
  • From: ghiureai
• Slow index scan backward.
  • From: John van Breda
• Re: Updating large tables without dead tuples
  • From: Vik Fearing
• Re: why does this query not use a parallel query
  • From: Tom Lane
• why does this query not use a parallel query
  • From: Dave Cramer
• Re: Performance degrade in Planning Time to find appropriate Partial Index
  • From: Pavel Stehule
• Re: Performance degrade in Planning Time to find appropriate Partial Index
  • From: Pavel Stehule
• Re: Performance degrade in Planning Time to find appropriate Partial Index
  • From: Nandakumar M
• Re: Performance degrade in Planning Time to find appropriate Partial Index
  • From: Moreno Andreo
• Re: Performance degrade in Planning Time to find appropriate Partial Index
  • From: Michael Loftis
• Re: Performance degrade in Planning Time to find appropriate Partial Index
  • From: Laurenz Albe
• Performance degrade in Planning Time to find appropriate Partial Index
  • From: Meenatchi Sandanam
• check_postgres via Nagios
  • From: daulat sagar
• Re: Performance
  • From: phb07
• Re: Please help
  • From: PropAAS DBA
• Re: Updating large tables without dead tuples
  • From: Stephen Frost
• RE: Updating large tables without dead tuples
  • From: ldh@xxxxxxxxxxxxxxxxxx
• Re: Bitmap scan is undercosted?
  • From: Vitaliy Garnashevich
• Re: Updating large tables without dead tuples
  • From: Stephen Frost
• Updating large tables without dead tuples
  • From: ldh@xxxxxxxxxxxxxxxxxx
• Re: Please help
  • From: Andreas Kretschmer
• Re: Performance
  • From: Andreas Kretschmer
• Please help
  • From: Daulat Ram
• Performance
  • From: Daulat Ram
• Re: effective_io_concurrency on EBS/gp2
  • From: Vitaliy Garnashevich
• Re: need advice to tune postgresql
  • From: Laurenz Albe
• Re: effective_io_concurrency on EBS/gp2
  • From: Rick Otten
• Re: need advice to tune postgresql
  • From: MichaelDBA
• need advice to tune postgresql
  • From: Darius Pėža
• Re: blending fast and temp space volumes
  • From: Claudio Freire
• Re: blending fast and temp space volumes
  • From: Peter Geoghegan
• Re: blending fast and temp space volumes
  • From: Claudio Freire
• Re: blending fast and temp space volumes
  • From: Peter Geoghegan
• Re: blending fast and temp space volumes
  • From: Craig James
• Re: blending fast and temp space volumes
  • From: Tom Lane
• blending fast and temp space volumes
  • From: Rick Otten
• Re: Efficiently searching for the most recent rows where a column matches any result from a different query
  • From: Nandakumar M
• Re: Efficiently searching for the most recent rows where a column matches any result from a different query
  • From: Nandakumar M
• Re: pgpool 2 rotate logs
  • From: Tatsuo Ishii
• pgpool 2 rotate logs
  • From: Mariel Cherkassky
• Re: Efficiently searching for the most recent rows where a column matches any result from a different query
  • From: mkslaf
• Re: OT: Performance of VM
  • From: Mark Kirkwood
• Re: Details after Load Peak was: OT: Performance of VM
  • From: Micky Gough
• Re: Details after Load Peak was: OT: Performance of VM
  • From: Gunnar "Nick" Bluth
• Re: Efficiently searching for the most recent rows where a column matches any result from a different query
  • From: Hellmuth Vargas
• Efficiently searching for the most recent rows where a column matches any result from a different query
  • From: mkslaf
• Re: OT: Performance of VM
  • From: Andrew Kerber
• Re: OT: Performance of VM
  • From: Robert Klemme
• Same plans different performance?
  • From: Elias Panagiotidis
• Re: effective_io_concurrency on EBS/gp2
  • From: Vitaliy Garnashevich
• Re: effective_io_concurrency on EBS/gp2
  • From: Vitaliy Garnashevich
• Re: failing to use index on UNION of matviews (Re: postgresql 10.1 wrong plan in when using partitions bug)
  • From: Rick Otten
• RE: pg_xlog unbounded growth
  • From: Alex Ignatov
• Re: effective_io_concurrency on EBS/gp2
  • From: Justin Pryzby
• Re: failing to use index on UNION of matviews (Re: postgresql 10.1 wrong plan in when using partitions bug)
  • From: Rick Otten
• Re: failing to use index on UNION of matviews (Re: postgresql 10.1 wrong plan in when using partitions bug)
  • From: Rick Otten
• Re: failing to use index on UNION of matviews (Re: postgresql 10.1 wrong plan in when using partitions bug)
  • From: Justin Pryzby
• Re: Details after Load Peak was: OT: Performance of VM
  • From: Alan Hodgson
• Details after Load Peak was: OT: Performance of VM
  • From: Thomas Güttler
• Re: effective_io_concurrency on EBS/gp2
  • From: Claudio Freire
• Re: postgresql 10.1 wrong plan in when using partitions bug
  • From: Justin Pryzby
• Re: SV: bad plan using nested loops
  • From: Tomas Vondra
• Re: OT: Performance of VM
  • From: Andreas Kretschmer
• Re: OT: Performance of VM
  • From: Andrew Kerber
• Re: OT: Performance of VM
  • From: Andreas Kretschmer
• OT: Performance of VM
  • From: Thomas Güttler
• Re: effective_io_concurrency on EBS/gp2
  • From: Vitaliy Garnashevich
• Re: effective_io_concurrency on EBS/gp2
  • From: Claudio Freire
• Re: postgresql 10.1 wrong plan in when using partitions bug
  • From: Rick Otten
• Re: postgresql 10.1 wrong plan in when using partitions bug
  • From: Mariel Cherkassky
• Re: postgresql 10.1 wrong plan in when using partitions bug
  • From: Tom Lane
• Re: postgresql 10.1 wrong plan in when using partitions bug
  • From: Tom Lane
• Re: postgresql 10.1 wrong plan in when using partitions bug
  • From: Mariel Cherkassky
• Re: postgresql 10.1 wrong plan in when using partitions bug
  • From: Justin Pryzby
• Re: postgresql 10.1 wrong plan in when using partitions bug
  • From: Mariel Cherkassky
• Re: postgresql 10.1 wrong plan in when using partitions bug
  • From: Andreas Kretschmer
• Re: postgresql 10.1 wrong plan in when using partitions bug
  • From: Mariel Cherkassky
• Re: postgresql 10.1 wrong plan in when using partitions bug
  • From: Mariel Cherkassky
• Re: postgresql 10.1 wrong plan in when using partitions bug
  • From: Rick Otten
• Re: postgresql 10.1 wrong plan in when using partitions bug
  • From: legrand legrand
• Re: postgresql 10.1 wrong plan in when using partitions bug
  • From: Mariel Cherkassky
• Re: postgresql 10.1 wrong plan in when using partitions bug
  • From: legrand legrand
• Re: postgresql 10.1 wrong plan in when using partitions bug
  • From: Mariel Cherkassky
• Re: postgresql 10.1 wrong plan in when using partitions bug
  • From: Rick Otten
• Re: postgresql 10.1 wrong plan in when using partitions bug
  • From: Tomas Vondra
• postgresql 10.1 wrong plan in when using partitions bug
  • From: Mariel Cherkassky
• Re: postgresql 10.1 scanning all partitions instead of 1
  • From: Mariel Cherkassky
• postgresql 10.1 scanning all partitions instead of 1
  • From: Mariel Cherkassky
• Re: effective_io_concurrency on EBS/gp2
  • From: Vitaliy Garnashevich
• Re: Query optimiser is not using 'not null' constraint when 'order by nulls last' clause is used
  • From: Nandakumar M
• Re: Query optimiser is not using 'not null' constraint when 'order by nulls last' clause is used
  • From: David G. Johnston
• Re: Query optimiser is not using 'not null' constraint when 'order by nulls last' clause is used
  • From: Nandakumar M
• Re: Query optimiser is not using 'not null' constraint when 'order by nulls last' clause is used
  • From: Tom Lane
• Re: Query optimiser is not using 'not null' constraint when 'order by nulls last' clause is used
  • From: Nandakumar M
• Re: effective_io_concurrency on EBS/gp2
  • From: Vitaliy Garnashevich
• Re: Query optimiser is not using 'not null' constraint when 'order by nulls last' clause is used
  • From: Laurenz Albe
• Re: SV: bad plan using nested loops
  • From: Johan Fredriksson
• SV: bad plan using nested loops
  • From: Johan Fredriksson
• Re: effective_io_concurrency on EBS/gp2
  • From: Claudio Freire
• Re: bad plan using nested loops
  • From: Tom Lane
• Query optimiser is not using 'not null' constraint when 'order by nulls last' clause is used
  • From: Nandakumar M
• bad plan using nested loops
  • From: Johan Fredriksson
• Re: 8.2 Autovacuum BUG ?
  • From: pavan95
• Re: effective_io_concurrency on EBS/gp2
  • From: hzzhangjiazhi
• Re: effective_io_concurrency on EBS/gp2
  • From: Jeff Janes
• Re: effective_io_concurrency on EBS/gp2
  • From: Vitaliy Garnashevich
• Re: effective_io_concurrency on EBS/gp2
  • From: Claudio Freire
• Re: effective_io_concurrency on EBS/gp2
  • From: Vitaliy Garnashevich
• RE: effective_io_concurrency on EBS/gp2
  • From: Gary Doades
• Re: effective_io_concurrency on EBS/gp2
  • From: Pavel Stehule
• Re: effective_io_concurrency on EBS/gp2
  • From: Vitaliy Garnashevich
• Re: effective_io_concurrency on EBS/gp2
  • From: Rick Otten
• effective_io_concurrency on EBS/gp2
  • From: Vitaliy Garnashevich
• Re: Nested Loops
  • From: Laurenz Albe
• Nested Loops
  • From: Kumar, Virendra
• Re: 8.2 Autovacuum BUG ?
  • From: Claudio Freire
• Re: SV: pgaudit and create postgis extension logs a lot inserts
  • From: Bruce Momjian
• Re: 8.2 Autovacuum BUG ?
  • From: pavan95
• Re: dsa_allocate() faliure
  • From: Rick Otten
• Re: dsa_allocate() faliure
  • From: Thomas Munro
• Re: dsa_allocate() faliure
  • From: Tom Lane
• dsa_allocate() faliure
  • From: Rick Otten
• PostgreSQL 10.1 partitions and indexes
  • From: Mariel Cherkassky
• Re: 8.2 Autovacuum BUG ?
  • From: Pavan Teja
• Re: performance drop after upgrade (9.6 > 10)
  • From: Bruce Momjian
• Re: Query Slow After 2018
  • From: David G. Johnston
• Re: Query Slow After 2018
  • From: Justin Pryzby
• Query Slow After 2018
  • From: Nur Agus
• SV: copy csv into partitioned table with unique index
  • From: Lars Aksel Opsahl
• SV: copy csv into partitioned table with unique index
  • From: Lars Aksel Opsahl
• Re: copy csv into partitioned table with unique index
  • From: legrand legrand
• copy csv into partitioned table with unique index
  • From: Mariel Cherkassky
• PG 10 hash index create times
  • From: Rick Otten
• Re: pg_xlog unbounded growth
  • From: Andreas Kretschmer
• Re: Query is slow when run for first time; subsequent execution is fast
  • From: Nandakumar M
• Re: 8.2 Autovacuum BUG ?
  • From: Pavan Teja
• Re: pg_xlog unbounded growth
  • From: Tomas Vondra
• Re: 8.2 Autovacuum BUG ?
  • From: Alvaro Herrera
• Re: pg_xlog unbounded growth
  • From: Laurenz Albe
• Re: 8.2 Autovacuum BUG ?
  • From: pavan95
• Re: 8.2 Autovacuum BUG ?
  • From: Alvaro Herrera
• Re: 8.2 Autovacuum BUG ?
  • From: David G. Johnston
• Re: 8.2 Autovacuum BUG ?
  • From: Pavan Teja
• Re: 8.2 Autovacuum BUG ?
  • From: Claudio Freire
• Re: 8.2 Autovacuum BUG ?
  • From: pavan95
• pg_xlog unbounded growth
  • From: Stefan Petrea
• Re: need help on memory allocation
  • From: Vitaliy Garnashevich
• Re: 8.2 Autovacuum BUG ?
  • From: Claudio Freire
• Re: need help on memory allocation
  • From: pavan95
• Re: need help on memory allocation
  • From: Michael Paquier
• Re: Performance impact of lowering max_files_per_process
  • From: Thomas Kellerer
• Re: 8.2 Autovacuum BUG ?
  • From: pavan95
• Re: need help on memory allocation
  • From: pavan95
• Re: need help on memory allocation
  • From: Jeff Janes
• Re: 8.2 Autovacuum BUG ?
  • From: Claudio Freire
• Re: need help on memory allocation
  • From: Laurenz Albe
• Re: Bad plan
  • From: Matthew Bellew
• Re: 8.2 Autovacuum BUG ?
  • From: Pavan Teja
• Re: 8.2 Autovacuum BUG ?
  • From: Claudio Freire
• RE: Inefficient full seq scan on pg_largeobject instead of index scan
  • From: Jean-Marc Lessard
• Re: 8.2 Autovacuum BUG ?
  • From: pavan95
• Re: Bad plan
  • From: Laurent Martelli
• Re: Bad plan
  • From: Laurent Martelli
• Re: 8.2 Autovacuum BUG ?
  • From: Andreas Kretschmer
• Re: 8.2 Autovacuum BUG ?
  • From: Pavan Teja
• Re: Bad plan
  • From: Justin Pryzby
• Re: 8.2 Autovacuum BUG ?
  • From: Andreas Kretschmer
• Re: 8.2 Autovacuum BUG ?
  • From: David G. Johnston
• Re: 8.2 Autovacuum BUG ?
  • From: Pavan Teja
• Re: 8.2 Autovacuum BUG ?
  • From: Andreas Kretschmer
• Re: need help on memory allocation
  • From: Andreas Kretschmer
• Re: need help on memory allocation
  • From: Rambabu V
• Bad plan
  • From: Laurent Martelli
• Re: 8.2 Autovacuum BUG ?
  • From: pavan95
• PG 9.6 Slow inserts with long-lasting LWLocks
  • From: Pavel Suderevsky
• Re: 8.2 Autovacuum BUG ?
  • From: Andreas Kretschmer
• Re: 8.2 Autovacuum BUG ?
  • From: pavan95
• Re: 8.2 Autovacuum BUG ?
  • From: Sergei Kornilov
• Re: 8.2 Autovacuum BUG ?
  • From: pavan95
• SV: pgaudit and create postgis extension logs a lot inserts
  • From: Svensson Peter
• query execution time (with cache)
  • From: Neto pr
• Re: pgaudit and create postgis extension logs a lot inserts
  • From: Magnus Hagander
• Performance impact of lowering max_files_per_process
  • From: Thomas Kellerer
• Re: pgaudit and create postgis extension logs a lot inserts
  • From: David Steele
• Re: pgaudit and create postgis extension logs a lot inserts
  • From: David Steele
• RE: pgaudit and create postgis extension logs a lot inserts
  • From: Karen Stone
• Re: pgaudit and create postgis extension logs a lot inserts
  • From: Magnus Hagander
• SV: pgaudit and create postgis extension logs a lot inserts
  • From: Svensson Peter
• Re: need help on memory allocation
  • From: Laurenz Albe
• Re: pgaudit and create postgis extension logs a lot inserts
  • From: Joe Conway
• need help on memory allocation
  • From: Rambabu V
• pgaudit and create postgis extension logs a lot inserts
  • From: Svensson Peter
• Re: Query is slow when run for first time; subsequent execution is fast
  • From: Michael Paquier
• RE: Query is slow when run for first time; subsequent execution is fast
  • From: Nandakumar M
• RE: Query is slow when run for first time; subsequent execution is fast
  • From: POUSSEL, Guillaume
• Re: Query is slow when run for first time; subsequent execution is fast
  • From: Jeff Janes
• Re: HDD vs SSD without explanation
  • From: Mark Kirkwood
• Re: HDD vs SSD without explanation
  • From: Nicolas Charles
• Re: Query is slow when run for first time; subsequent execution is fast
  • From: Thomas Kellerer
• Fwd: Re: Query is slow when run for first time; subsequent execution is fast
  • From: Nandakumar M
• Re: HDD vs SSD without explanation
  • From: Neto pr
• Re: HDD vs SSD without explanation
  • From: Mark Kirkwood
• Re: HDD vs SSD without explanation
  • From: Neto pr
• Re: HDD vs SSD without explanation
  • From: Justin Pryzby
• Re: HDD vs SSD without explanation
  • From: Neto pr
• Re: HDD vs SSD without explanation
  • From: Fernando Hevia
• Re: HDD vs SSD without explanation
  • From: Neto pr
• Re: HDD vs SSD without explanation
  • From: Neto pr
• Re: HDD vs SSD without explanation
  • From: Fernando Hevia
• Re: HDD vs SSD without explanation
  • From: Brian Busch
• Re: HDD vs SSD without explanation
  • From: Georg H.
• Re: HDD vs SSD without explanation
  • From: Neto pr
• Re: HDD vs SSD without explanation
  • From: Neto pr
• Re: HDD vs SSD without explanation
  • From: Justin Pryzby
• Re: HDD vs SSD without explanation
  • From: Neto pr
• Re: HDD vs SSD without explanation
  • From: Neto pr
• Re: HDD vs SSD without explanation
  • From: Neto pr
• Re: HDD vs SSD without explanation
  • From: Justin Pryzby
• HDD vs SSD without explanation
  • From: Neto pr
• Re: Re: PGadmin error while connecting with database.
  • From: Dinesh Chandra 12108
• Re: Query is slow when run for first time; subsequent execution is fast
  • From: Pavel Stehule
• Re: PGadmin error while connecting with database.
  • From: Mariel Cherkassky
• RE: Slow queries after Windows startup
  • From: Éric Fontaine
• Re: Query is slow when run for first time; subsequent execution is fast
  • From: Nandakumar M
• PGadmin error while connecting with database.
  • From: Dinesh Chandra 12108
• Disjunctions and sequential scans
  • From: Ronuk Raval
• RE: Slow queries after Windows startup
  • From: POUSSEL, Guillaume
• Re: Slow queries after Windows startup
  • From: Robert Zenz
• RE: Slow queries after Windows startup
  • From: POUSSEL, Guillaume
• Re: Slow queries after Windows startup
  • From: Robert Zenz
• Slow queries after Windows startup
  • From: POUSSEL, Guillaume
• Re: Query is slow when run for first time; subsequent execution is fast
  • From: Jeff Janes
• Query is slow when run for first time; subsequent execution is fast
  • From: Nandakumar M
• Re: PG 9.5 2 tables same DDL with diff size
  • From: ghiureai
• RE: PG 9.5 2 tables same DDL with diff size
  • From: Igor Neyman
• RE: PG 9.5 2 tables same DDL with diff size
  • From: Isabella Ghiurea
• RE: PG 9.5 2 tables same DDL with diff size
  • From: Igor Neyman
• Re: View preformance oracle to postgresql
  • From: Merlin Moncure
• RE: Re: Unable to connect Postgres using psql while postgres is already running.
  • From: Dinesh Chandra 12108
• Re: View preformance oracle to postgresql
  • From: Laurenz Albe
• View preformance oracle to postgresql
  • From: Reddygari, Pavan
• Re: Unable to connect Postgres using psql while postgres is already running.
  • From: Laurenz Albe
• Unable to connect Postgres using psql while postgres is already running.
  • From: Dinesh Chandra 12108
• Re: Performance of a Query
  • From: Laurenz Albe
• RE: Performance of a Query
  • From: Danylo Hlynskyi
• Re: Need Help on wal_compression
  • From: Michael Paquier
• Re: Performance of a Query
  • From: Scott Marlowe
• RE: Performance of a Query
  • From: Kumar, Virendra
• Re: Performance of a Query
  • From: Scott Marlowe
• PG 9.5 2 tables same DDL with diff size
  • From: ghiureai
• RE: Performance of a Query
  • From: Kumar, Virendra
• Re: Performance of a Query
  • From: Scott Marlowe
• Re: Need Help on wal_compression
  • From: Jeff Janes
• Performance of a Query
  • From: Kumar, Virendra
• Re: Need Help on wal_compression
  • From: Scott Marlowe
• Re: Batch insert heavily affecting query performance.
  • From: Claudio Freire
• Re: Need Help on wal_compression
  • From: Claudio Freire
• Re: Updating a large table
  • From: Timokhin Maxim
• Need Help on wal_compression
  • From: Rambabu V
• Re: Updating a large table
  • From: Sergei Kornilov
• Re: Updating a large table
  • From: Timokhin Maxim
• seeing lag in postgresql replication
  • From: Rambabu V
• Re: seeing lag in postgresql replication
  • From: Mariel Cherkassky
• Re: GEQO and join_collapse_limit correlation
  • From: Juan José Santamaría Flecha
• Re: GEQO and join_collapse_limit correlation
  • From: Tom Lane
• Re: GEQO and join_collapse_limit correlation
  • From: Juan José Santamaría Flecha
• Re: GEQO and join_collapse_limit correlation
  • From: Tom Lane
• GEQO and join_collapse_limit correlation
  • From: Juan José Santamaría Flecha
• Re: primary key hash index
  • From: Jeff Janes
• Re: primary key hash index
  • From: Magnus Hagander
• primary key hash index
  • From: Rick Otten
• Re: Restoring a table is ten times slower on Ubuntu 14.04 than on Ubuntu 16.04
  • From: Vasilis Ventirozos
• Restoring a table is ten times slower on Ubuntu 14.04 than on Ubuntu 16.04
  • From: Hans Braxmeier
• Re: partitioning an existing table - efficient pg_dump
  • From: Justin Pryzby
• Re: partitioning an existing table
  • From: Robert Blayzor
• analyze stats: child vs parent
  • From: Justin Pryzby
• Re: partitioning an existing table
  • From: Justin Pryzby
• partitioning an existing table
  • From: Robert Blayzor
• Re: Table performance with millions of rows (partitioning)
  • From: pinker
• Re: Table performance with millions of rows (partitioning)
  • From: Robert Blayzor
• Re: Table performance with millions of rows (partitioning)
  • From: Justin Pryzby
• Table performance with millions of rows
  • From: Robert Blayzor
• Re: Batch insert heavily affecting query performance.
  • From: David Miller
• RE: Batch insert heavily affecting query performance.
  • From: Mike Sofen
• Re: Batch insert heavily affecting query performance.
  • From: Alvaro Hernandez
• Re: Batch insert heavily affecting query performance.
  • From: Jean Baro
• Re: Batch insert heavily affecting query performance.
  • From: Jean Baro
• RE: Batch insert heavily affecting query performance.
  • From: Jean Baro
• Re: Batch insert heavily affecting query performance.
  • From: Jean Baro
• Re: Batch insert heavily affecting query performance.
  • From: Jean Baro
• Re: Batch insert heavily affecting query performance.
  • From: Jeff Janes
• Re: Batch insert heavily affecting query performance.
  • From: Jeremy Finzel
• RE: Batch insert heavily affecting query performance.
  • From: Mike Sofen
• Re: Batch insert heavily affecting query performance.
  • From: Rick Otten
• Re: Batch insert heavily affecting query performance.
  • From: Jean Baro
• Re: Batch insert heavily affecting query performance.
  • From: Jean Baro
• Re: Batch insert heavily affecting query performance.
  • From: Danylo Hlynskyi
• Re: Batch insert heavily affecting query performance.
  • From: MichaelDBA
• Re: Batch insert heavily affecting query performance.
  • From: Jean Baro
• Re: Batch insert heavily affecting query performance.
  • From: MichaelDBA@xxxxxxxxxxx
• Batch insert heavily affecting query performance.
  • From: Jean Baro
• Re: Updating a large table
  • From: Tomas Vondra
• Re: Updating a large table
  • From: salah jubeh
• Updating a large table
  • From: Timokhin Maxim
• Re: Autoanalyze CPU usage
  • From: Habib Nahas
• Re: Autoanalyze CPU usage
  • From: Nikolay Samokhvalov
• Re: Autoanalyze CPU usage
  • From: Laurenz Albe
• Re: Autoanalyze CPU usage
  • From: Michaeldba@xxxxxxxxxxx
• Re: Autoanalyze CPU usage
  • From: Justin Pryzby
• Re: Autoanalyze CPU usage
  • From: Habib Nahas
• Re: Autoanalyze CPU usage
  • From: Habib Nahas
• Re: Autoanalyze CPU usage
  • From: Tomas Vondra
• Re: Autoanalyze CPU usage
  • From: Justin Pryzby
• Autoanalyze CPU usage
  • From: Habib Nahas
• Re: WHERE IN for JOIN subquery?
  • From: Dave Johansen
• Re: WHERE IN for JOIN subquery?
  • From: David G. Johnston
• WHERE IN for JOIN subquery?
  • From: Dave Johansen
• Re: Bitmap scan is undercosted? - overestimated correlation and cost_index
  • From: Justin Pryzby
• Re: Bitmap scan is undercosted? - overestimated correlation and cost_index
  • From: Justin Pryzby
• Re: Bitmap scan is undercosted? - overestimated correlation and cost_index
  • From: Justin Pryzby
• Re: CPU 100% usage caused by unknown postgres process..
  • From: Tomas Vondra
• Re: CPU 100% usage caused by unknown postgres process..
  • From: Justin Pryzby
• Re: CPU 100% usage caused by unknown postgres process..
  • From: Laurenz Albe
• CPU 100% usage caused by unknown postgres process..
  • From: Dinesh Chandra 12108
• Re: PostgreSQL database size is not reasonable
  • From: Tom Lane
• Re: PostgreSQL database size is not reasonable
  • From: Mariel Cherkassky
• Re: PostgreSQL database size is not reasonable
  • From: Tom Lane
• RE: PostgreSQL database size is not reasonable
  • From: Craig McIlwee
• Re: PostgreSQL database size is not reasonable
  • From: David G. Johnston
• PostgreSQL database size is not reasonable
  • From: Mariel Cherkassky
• Re: Bitmap scan is undercosted? - overestimated correlation and cost_index
  • From: Jeff Janes
• Re: Bitmap scan is undercosted?
  • From: Jeff Janes
• Re: Prepared Transactions
  • From: jwhiting
• Re: Prepared Transactions
  • From: Sergei Kornilov
• Prepared Transactions
  • From: Riaan Stander
• Re: Learning EXPLAIN
  • From: Sam Gendler
• Re: Learning EXPLAIN
  • From: Sam Gendler
• Faster str to int conversion (was Table with large number of int columns, very slow COPY FROM)
  • From: Andres Freund
• Re: Table with large number of int columns, very slow COPY FROM
  • From: Andres Freund
• Re: Learning EXPLAIN
  • From: Gustavo Velasquez
• Re: Learning EXPLAIN
  • From: Flavio Henrique Araque Gurgel
• Re: Learning EXPLAIN
  • From: Guillaume Lelarge
• Re: Table with large number of int columns, very slow COPY FROM
  • From: Andreas Kretschmer
• Re: Setting effective_io_concurrency in VM?
  • From: Mark Kirkwood
• Table with large number of int columns, very slow COPY FROM
  • From: Alex Tokarev
• Learning EXPLAIN
  • From: Flávio Henrique
• Re: pg_dump 3 times as slow after 8.4 -> 9.5 upgrade
  • From: Claudio Freire
• Re: pg_dump 3 times as slow after 8.4 -> 9.5 upgrade
  • From: Laurenz Albe
• Re: Slow execution of SET ROLE, SET search_path and RESET ROLE
  • From: Tom Lane
• Re: Slow execution of SET ROLE, SET search_path and RESET ROLE
  • From: Ulf Lohbrügge
• Re: Slow execution of SET ROLE, SET search_path and RESET ROLE
  • From: Tom Lane
• Re: Slow execution of SET ROLE, SET search_path and RESET ROLE
  • From: Ulf Lohbrügge
• Re: pg_dump 3 times as slow after 8.4 -> 9.5 upgrade
  • From: Gunther
• Re: Bitmap scan is undercosted? - boolean correlation
  • From: Jeff Janes
• Re: Bitmap scan is undercosted?
  • From: Jeff Janes
• Re: insert and query performance on big string table with pg_trgm
  • From: Matthew Hall
• Re: Bitmap scan is undercosted?
  • From: Vitaliy Garnashevich
• Re: Bitmap scan is undercosted? - overestimated correlation and cost_index
  • From: Justin Pryzby
• Re: Different plan chosen when in lateral subquery
  • From: Laurenz Albe
• Re: insert and query performance on big string table with pg_trgm
  • From: Sergei Kornilov
• Re: Bitmap scan is undercosted?
  • From: Vitaliy Garnashevich
• Re: insert and query performance on big string table with pg_trgm
  • From: Matthew Hall
• Re: Half billion records in one table? RDS
  • From: Aaron Werman
• Re: Bitmap scan is undercosted? - boolean correlation
  • From: Tom Lane
• Re: Extremely slow DELETE with cascade foreign keys
  • From: Rodrigo Rosenfeld Rosas
• Re: Different plan chosen when in lateral subquery
  • From: Alex Reece
• Re: Extremely slow DELETE with cascade foreign keys
  • From: Rodrigo Rosenfeld Rosas
• Re: Different plan chosen when in lateral subquery
  • From: Alex Reece
• Different plan chosen when in lateral subquery
  • From: Alex Reece
• Re: Extremely slow DELETE with cascade foreign keys
  • From: Alvaro Herrera
• Re: Extremely slow DELETE with cascade foreign keys
  • From: Rodrigo Rosenfeld Rosas
• Re: Extremely slow DELETE with cascade foreign keys
  • From: Tom Lane
• Re: Extremely slow DELETE with cascade foreign keys
  • From: Rodrigo Rosenfeld Rosas
• Re: Extremely slow DELETE with cascade foreign keys
  • From: Alvaro Herrera
• Re: Extremely slow DELETE with cascade foreign keys
  • From: Rodrigo Rosenfeld Rosas
• Re: Extremely slow DELETE with cascade foreign keys
  • From: Tom Lane
• Extremely slow DELETE with cascade foreign keys
  • From: Rodrigo Rosenfeld Rosas
• Re: vacuum after truncate
  • From: Laurenz Albe
• vacuum after truncate
  • From: Mariel Cherkassky
• Re: Bitmap scan is undercosted? - boolean correlation
  • From: Jeff Janes
• Re: Bitmap scan is undercosted? - boolean correlation
  • From: Tom Lane
• Re: Bitmap scan is undercosted? - boolean correlation
  • From: Jeff Janes
• Re: Bitmap scan is undercosted?
  • From: Tom Lane
• Re: Bitmap scan is undercosted?
  • From: Vitaliy Garnashevich
• Re: Bitmap scan is undercosted?
  • From: Vitaliy Garnashevich
• Re: Bitmap scan is undercosted?
  • From: Vitaliy Garnashevich
• Re: Bitmap scan is undercosted? - boolean correlation
  • From: Justin Pryzby
• Re: Bitmap scan is undercosted?
  • From: Jeff Janes
• Re: Bitmap scan is undercosted?
  • From: Tom Lane
• Re: Bitmap scan is undercosted?
  • From: Jeff Janes
• Re: Bitmap scan is undercosted?
  • From: Vitaliy Garnashevich
• Re: Bitmap scan is undercosted?
  • From: Justin Pryzby
• Re: Bitmap scan is undercosted?
  • From: Jeff Janes
• Re: Bad plan for ltree predicate <@
  • From: Roman Konoval
• Re: Bitmap scan is undercosted?
  • From: Justin Pryzby
• Re: Bitmap scan is undercosted?
  • From: Vitaliy Garnashevich
• Re: Bitmap scan is undercosted?
  • From: Justin Pryzby
• Re: Bitmap scan is undercosted?
  • From: Vitaliy Garnashevich
• Re: Bad plan for ltree predicate <@
  • From: Tom Lane
• ODBC--call failed :: Bindings were not allocated properly
  • From: Dinesh Chandra 12108
• Re: Half billion records in one table? RDS
  • From: Laurenz Albe
• Half billion records in one table? RDS
  • From: Jean Baro
• Re: Query became very slow after 9.6 -> 10 upgrade
  • From: Dmitry Shalashov
• Re: Query became very slow after 9.6 -> 10 upgrade
  • From: Tom Lane
• Re: Query became very slow after 9.6 -> 10 upgrade
  • From: Dmitry Shalashov
• Re: Query became very slow after 9.6 -> 10 upgrade
  • From: Michael Paquier
• Re: Query became very slow after 9.6 -> 10 upgrade
  • From: Dmitry Shalashov
• Re: Query became very slow after 9.6 -> 10 upgrade
  • From: Tom Lane
• Re: Query became very slow after 9.6 -> 10 upgrade
  • From: Dmitry Shalashov
• RE: Re: Re: Re: Issue with postgres login
  • From: Daulat Ram
• Re: Re: Re: Issue with postgres login
  • From: Bob Strecansky
• RE: Re: Re: Issue with postgres login
  • From: Daulat Ram
• Re: Re: Issue with postgres login
  • From: Bob Strecansky
• RE: Re: Issue with postgres login
  • From: Daulat Ram
• Re: Issue with postgres login
  • From: Bob Strecansky
• Issue with postgres login
  • From: Daulat Ram
• pgpool + repmgr - who should be responsible for failover
  • From: Mariel Cherkassky
• Re: Query became very slow after 9.6 -> 10 upgrade
  • From: Tom Lane
• Re: Query became very slow after 9.6 -> 10 upgrade
  • From: Dmitry Shalashov
• Re: Query became very slow after 9.6 -> 10 upgrade
  • From: Tom Lane
• Re: Query became very slow after 9.6 -> 10 upgrade
  • From: Dmitry Shalashov
• Re: Query became very slow after 9.6 -> 10 upgrade
  • From: Tom Lane
• Re: Query became very slow after 9.6 -> 10 upgrade
  • From: Tomas Vondra
• Re: Query became very slow after 9.6 -> 10 upgrade
  • From: Dmitry Shalashov
• RE: Query became very slow after 9.6 -> 10 upgrade
  • From: Alex Ignatov
• Re: Query became very slow after 9.6 -> 10 upgrade
  • From: Dmitry Shalashov
• RE: Query became very slow after 9.6 -> 10 upgrade
  • From: Alex Ignatov
• Query became very slow after 9.6 -> 10 upgrade
  • From: Dmitry Shalashov
• Re: Using GROUPING SETS with more than one set disables predicate pushdown?
  • From: Andres Freund
• Re: pg_dump 3 times as slow after 8.4 -> 9.5 upgrade
  • From: Shaul Dar
• Re: POWA doesn't show queries executed
  • From: Marco Nietz
• Re: Using GROUPING SETS with more than one set disables predicate pushdown?
  • From: Tom Lane
• Using GROUPING SETS with more than one set disables predicate pushdown?
  • From: Zakhar Shapurau
• Re: POWA doesn't show queries executed
  • From: phb07
• Migration to PGLister - After
  • From: Stephen Frost
• Migration to pglister - Before
  • From: Stephen Frost
• Re: PostgreSQL 9.6 wals management
  • From: Mariel Cherkassky
• Re: PostgreSQL 9.6 wals management
  • From: Michael Paquier
• PostgreSQL 9.6 wals management
  • From: Mariel Cherkassky
• POWA doesn't show queries executed
  • From: Neto pr
• Re: CREATE STATISTICS and join selectivity
  • From: David Rowley
• CREATE STATISTICS and join selectivity
  • From: Justin Pryzby
• Re: query performance issue
  • From: Pavel Stehule
• Re: query performance issue
  • From: Gunther
• Re: Query planner gaining the ability to replanning after start of query execution.
  • From: Gunter
• Re: query performance issue
  • From: Justin Pryzby
• Re: query performance issue
  • From: Pavel Stehule
• Re: query performance issue
  • From: Samir Magar
• Re: query performance issue
  • From: Pavel Stehule
• query performance issue
  • From: Samir Magar
• Re: Query planner gaining the ability to replanning after start of query execution.
  • From: legrand legrand
• Re: Query planner gaining the ability to replanning after start of query execution.
  • From: Arne Roland
• Re: Query planner gaining the ability to replanning after start of query execution.
  • From: Arne Roland
• Re: Query planner gaining the ability to replanning after start of query execution.
  • From: Oliver Mattos
• Re: Query planner gaining the ability to replanning after start of query execution.
  • From: Tom Lane
• Re: Query planner gaining the ability to replanning after start of query execution.
  • From: Oliver Mattos
• Query planner gaining the ability to replanning after start of query execution.
  • From: Oliver Mattos
• Re: DB slowness after upgrade from Postgres 9.1 to 9.4
  • From: Tom Lane
• DB slowness after upgrade from Postgres 9.1 to 9.4
  • From: p kirti
• Re: overestimate on empty table
  • From: Tom Lane
• Re: overestimate on empty table
  • From: Justin Pryzby
• Re: overestimate on empty table
  • From: Tom Lane
• overestimate on empty table
  • From: Justin Pryzby
• Dynamic performance issues
  • From: Arne Roland
• Re: Slow execution of SET ROLE, SET search_path and RESET ROLE
  • From: Ulf Lohbrügge
• Re: Slow execution of SET ROLE, SET search_path and RESET ROLE
  • From: Tom Lane
• Re: Slow execution of SET ROLE, SET search_path and RESET ROLE
  • From: Ulf Lohbrügge
• Re: Slow execution of SET ROLE, SET search_path and RESET ROLE
  • From: Scott Marlowe
• Re: Slow execution of SET ROLE, SET search_path and RESET ROLE
  • From: Ulf Lohbrügge
• Re: Slow execution of SET ROLE, SET search_path and RESET ROLE
  • From: Andres Freund
• Re: Slow execution of SET ROLE, SET search_path and RESET ROLE
  • From: Ulf Lohbrügge
• Re: Slow execution of SET ROLE, SET search_path and RESET ROLE
  • From: Andres Freund
• Slow execution of SET ROLE, SET search_path and RESET ROLE
  • From: Ulf Lohbrügge
• Re: Performance loss upgrading from 9.3 to 9.6
  • From: Justin Pryzby
• Re: Performance loss upgrading from 9.3 to 9.6
  • From: Adam Brusselback
• Re: Performance loss upgrading from 9.3 to 9.6
  • From: Adam Torres
• Re: Index-Advisor Tools
  • From: Baron Schwartz
• Re: Performance loss upgrading from 9.3 to 9.6
  • From: Justin Pryzby
• Performance loss upgrading from 9.3 to 9.6
  • From: Adam Torres
• Re: Unnecessary DISTINCT while primary key in SQL
  • From: David Rowley
• Unnecessary DISTINCT while primary key in SQL
  • From: 刘瑞
• Re: Re: OLAP/reporting queries fall into nested loops over seq scans or other horrible planner choices
  • From: Dave Nicponski
• Re: Re: OLAP/reporting queries fall into nested loops over seq scans or other horrible planner choices
  • From: Gunther
• Re: OLAP/reporting queries fall into nested loops over seq scans or other horrible planner choices
  • From: legrand legrand
• Re: Re: OLAP/reporting queries fall into nested loops over seq scans or other horrible planner choices
  • From: Gunther
• Re: Re: OLAP/reporting queries fall into nested loops over seq scans or other horrible planner choices
  • From: Gunther
• Re: Re: OLAP/reporting queries fall into nested loops over seq scans or other horrible planner choices
  • From: Adam Brusselback
• Re: OLAP/reporting queries fall into nested loops over seq scans or other horrible planner choices
  • From: Thomas Kellerer
• Re: OLAP/reporting queries fall into nested loops over seq scans or other horrible planner choices
  • From: Laurenz Albe
• Re: OLAP/reporting queries fall into nested loops over seq scans or other horrible planner choices
  • From: legrand legrand
• Re: OLAP/reporting queries fall into nested loops over seq scans or other horrible planner choices
  • From: Gunther
• Re: OLAP/reporting queries fall into nested loops over seq scans or other horrible planner choices
  • From: Gunther
• Re: OLAP/reporting queries fall into nested loops over seq scans or other horrible planner choices
  • From: Laurenz Albe
• Re: OLAP/reporting queries fall into nested loops over seq scans or other horrible planner choices
  • From: ldh@xxxxxxxxxxxxxxxxxx
• OLAP/reporting queries fall into nested loops over seq scans or other horrible planner choices
  • From: Gunther
• Re: Cursor vs Set Operation
  • From: Merlin Moncure
• Cursor vs Set Operation
  • From: patibandlakoshal
• Re: Index-Advisor Tools
  • From: Julien Rouhaud
• Re: Index-Advisor Tools
  • From: Yves Dorfsman
• Re: Index-Advisor Tools
  • From: Alexandre de Arruda Paes
• Re: Index-Advisor Tools
  • From: Neto pr
• Re: Index-Advisor Tools
  • From: Anthony Sotolongo
• Index-Advisor Tools
  • From: Neto pr
• Massive insert vs heavy contention in LWLock:buffer_content
  • From: luisfpg
• Re: Cheaper subquery scan not considered unless offset 0
  • From: Tom Lane
• Re: Cheaper subquery scan not considered unless offset 0
  • From: Benjamin Coutu
• Re: Cheaper subquery scan not considered unless offset 0
  • From: Benjamin Coutu
• Re: Cheaper subquery scan not considered unless offset 0
  • From: David Rowley
• Cheaper subquery scan not considered unless offset 0
  • From: Benjamin Coutu
• Re: postgresql tuning with perf
  • From: Purav Chovatia
• Row-level security performance
  • From: Jason Borg
• Re: WAL still kept in pg_xlog even long after heavy workload is done
  • From: MichaelDBA
• WAL still kept in pg_xlog even long after heavy workload is done
  • From: Stefan Petrea
• Re: performance drop after upgrade (9.6 > 10)
  • From: Justin Pryzby
• Re: performance drop after upgrade (9.6 > 10)
  • From: Alvaro Herrera
• Re: performance drop after upgrade (9.6 > 10)
  • From: Johannes Graën
• Re: postgresql tuning with perf
  • From: legrand legrand
• Re: performance drop after upgrade (9.6 > 10)
  • From: Justin Pryzby
• Re: postgresql tuning with perf
  • From: Purav Chovatia
• Re: postgresql tuning with perf
  • From: Purav Chovatia
• Re: postgresql tuning with perf
  • From: legrand legrand
• Re: performance drop after upgrade (9.6 > 10)
  • From: johannes graën
• Re: postgresql tuning with perf
  • From: Purav Chovatia
• Re: postgresql tuning with perf
  • From: Purav Chovatia
• Re: postgresql tuning with perf
  • From: Steve Atkins
• Re: postgresql tuning with perf
  • From: Tomas Vondra
• Re: postgresql tuning with perf
  • From: legrand legrand
• postgresql tuning with perf
  • From: Purav Chovatia
• Re: Low priority batch insert
  • From: Michael Paquier
• Low priority batch insert
  • From: Jean Baro
• Re: memory allocation
  • From: Laurenz Albe
• memory allocation
  • From: nijam J
• Re: Row level security policy policy versus SQL constraints. Any performance difference?
  • From: Joe Carlson
• Re: Row level security policy policy versus SQL constraints. Any performance difference?
  • From: Tom Lane
• Re: Row level security policy policy versus SQL constraints. Any performance difference?
  • From: Tomas Vondra
• Row level security policy policy versus SQL constraints. Any performance difference?
  • From: Joe Carlson
• Re: 99% time spent in WAL wait events
  • From: Purav Chovatia
• 99% time spent in WAL wait events
  • From: Purav Chovatia
• Re: Stored Procedure Performance
  • From: phb07
• Re: Rowcount estimation changes based on from clause order
  • From: Ants Aasma
• Re: Rowcount estimation changes based on from clause order
  • From: Tom Lane
• Wrong plane for limit after group by
  • From: Денис Смирнов
• Re: synchronization between PostgreSQL and Oracle
  • From: Laurenz Albe
• Re: synchronization between PostgreSQL and Oracle
  • From: Rick Otten
• synchronization between PostgreSQL and Oracle
  • From: ROS Didier
• Re: blocking index creation
  • From: Scott Marlowe
• Re: blocking index creation
  • From: Neto pr
• Re: blocking index creation
  • From: Neto pr
• Re: blocking index creation
  • From: Tomas Vondra
• Re: Stored Procedure Performance
  • From: Pavel Stehule
• Re: Stored Procedure Performance
  • From: Adam Brusselback
• Re: Stored Procedure Performance
  • From: Purav Chovatia
• Re: Stored Procedure Performance
  • From: Adam Brusselback
• Re: Stored Procedure Performance
  • From: Purav Chovatia
• Re: Stored Procedure Performance
  • From: Pavel Stehule
• Re: blocking index creation
  • From: Neto pr
• Re: Stored Procedure Performance
  • From: Purav Chovatia
• Re: Stored Procedure Performance
  • From: Purav Chovatia
• Re: blocking index creation
  • From: Laurenz Albe
• blocking index creation
  • From: Neto pr
• Re: performance drop after upgrade (9.6 > 10)
  • From: johannes graën
• Re: performance drop after upgrade (9.6 > 10)
  • From: Pavel Stehule
• performance drop after upgrade (9.6 > 10)
  • From: johannes graën
• Rowcount estimation changes based on from clause order
  • From: Ants Aasma
• Cursor With_Hold Performance Workarounds/Optimization
  • From: Leon Winter
• Re: Regression from 9.4-9.6
  • From: Jim Nasby
• Re: Regression from 9.4-9.6
  • From: Tom Lane
• Re: Regression from 9.4-9.6
  • From: Jim Nasby
• Re: Regression from 9.4-9.6
  • From: Jim Nasby
• Re: Regression from 9.4-9.6
  • From: Tom Lane
• Regression from 9.4-9.6
  • From: Jim Nasby
• Re: How does max_parallel_workers_per_gather change load averages?
  • From: David Rowley
• Re: select with max functions
  • From: Mark Kirkwood
• How does max_parallel_workers_per_gather change load averages?
  • From: Ben Nachtrieb
• Re: Stored Procedure Performance
  • From: Pavel Stehule
• Re: Stored Procedure Performance
  • From: Adam Brusselback
• Re: Stored Procedure Performance
  • From: Laurenz Albe
• Stored Procedure Performance
  • From: Purav Chovatia
• Re: select with max functions
  • From: Tom Lane
• Re: select with max functions
  • From: Mariel Cherkassky
• Re: select with max functions
  • From: Gerardo Herzig
• Re: select with max functions
  • From: Mariel Cherkassky
• Re: select with max functions
  • From: Andreas Kretschmer
• Re: select with max functions
  • From: Gerardo Herzig
• select with max functions
  • From: Mariel Cherkassky
• Re: BDR, wal sender, high system cpu, mutex_lock_common
  • From: milist ujang
• BDR, wal sender, high system cpu, mutex_lock_common
  • From: milist ujang
• Re: Slow query in JDBC
  • From: Dave Cramer
• Re: Slow query in JDBC
  • From: Subramaniam C
• Re: Slow query in JDBC
  • From: Jeff Janes
• Re: Slow query in JDBC
  • From: Subramaniam C
• Re: Slow query in JDBC
  • From: Dave Cramer
• Re: Slow query in JDBC
  • From: Subramaniam C
• Re: Slow query in JDBC
  • From: Dave Cramer
• Re: Slow query in JDBC
  • From: Subramaniam C
• Re: Slow query in JDBC
  • From: Pavy Philippe
• Re: Slow query in JDBC
  • From: Julien Rouhaud
• Re: Slow query in JDBC
  • From: Subramaniam C
• Re: Slow query in JDBC
  • From: Julien Rouhaud
• Slow query in JDBC
  • From: Subramaniam C
• Re: query of partitioned object doesnt use index in qa
  • From: Mike Broers
• Parallel sequential scan not supported for stored procedure with RETURN QUERY EXECUTE ?
  • From: Tobias Gierke
• Re: Query regarding EXPLAIN (ANALYZE,BUFFERS)
  • From: Pavel Stehule