Postgres Performance Date Index

• Thread Index

• Re: PgSQL 12 on WinSrv ~3x faster than on Linux
  • From: David Rowley
• PgSQL 12 on WinSrv ~3x faster than on Linux
  • From: Taras Savchuk
• Re: slow query with inline function on AWS RDS with RDS 24x large
  • From: Ayub Khan
• Re: slow query with inline function on AWS RDS with RDS 24x large
  • From: Pavel Stehule
• Re: slow query with inline function on AWS RDS with RDS 24x large
  • From: Ayub Khan
• Re: slow query with inline function on AWS RDS with RDS 24x large
  • From: Pavel Stehule
• slow query with inline function on AWS RDS with RDS 24x large
  • From: Ayub Khan
• Re: AWS forcing PG upgrade from v9.6 a disaster
  • From: Dean Gibson (DB Administrator)
• Re: AWS forcing PG upgrade from v9.6 a disaster
  • From: Justin Pryzby
• Re: AWS forcing PG upgrade from v9.6 a disaster
  • From: Dean Gibson (DB Administrator)
• Re: AWS forcing PG upgrade from v9.6 a disaster
  • From: Tom Lane
• Re: AWS forcing PG upgrade from v9.6 a disaster
  • From: Dean Gibson (DB Administrator)
• Re: AWS forcing PG upgrade from v9.6 a disaster
  • From: Christophe Pettus
• Re: AWS forcing PG upgrade from v9.6 a disaster
  • From: Dean Gibson (DB Administrator)
• Re: AWS forcing PG upgrade from v9.6 a disaster
  • From: Dean Gibson (DB Administrator)
• Re: AWS forcing PG upgrade from v9.6 a disaster
  • From: Andrew Dunstan
• Re: AWS forcing PG upgrade from v9.6 a disaster
  • From: Dean Gibson (DB Administrator)
• Re: AWS forcing PG upgrade from v9.6 a disaster
  • From: Dean Gibson (DB Administrator)
• Re: AWS forcing PG upgrade from v9.6 a disaster
  • From: Jan Wieck
• Re: AWS forcing PG upgrade from v9.6 a disaster
  • From: Alexey M Boltenkov
• Re: AWS forcing PG upgrade from v9.6 a disaster
  • From: Dean Gibson (DB Administrator)
• Re: AWS forcing PG upgrade from v9.6 a disaster
  • From: Christophe Pettus
• Re: AWS forcing PG upgrade from v9.6 a disaster
  • From: Andrew Dunstan
• Re: AWS forcing PG upgrade from v9.6 a disaster
  • From: Jan Wieck
• Re: AWS forcing PG upgrade from v9.6 a disaster
  • From: Dean Gibson (DB Administrator)
• Re: AWS forcing PG upgrade from v9.6 a disaster
  • From: Bob Lunney
• Re: AWS forcing PG upgrade from v9.6 a disaster
  • From: Bruce Momjian
• Re: AWS forcing PG upgrade from v9.6 a disaster
  • From: Andrew Dunstan
• Re: AWS forcing PG upgrade from v9.6 a disaster
  • From: Pavel Stehule
• Re: AWS forcing PG upgrade from v9.6 a disaster
  • From: Dean Gibson (DB Administrator)
• Re: AWS forcing PG upgrade from v9.6 a disaster
  • From: Dean Gibson (DB Administrator)
• Re: AWS forcing PG upgrade from v9.6 a disaster
  • From: Jan Wieck
• Re: AWS forcing PG upgrade from v9.6 a disaster
  • From: Michael Lewis
• Re: AWS forcing PG upgrade from v9.6 a disaster
  • From: Ryan Bair
• Re: AWS forcing PG upgrade from v9.6 a disaster
  • From: MichaelDBA
• Re: AWS forcing PG upgrade from v9.6 a disaster
  • From: Campbell, Lance
• Re: AWS forcing PG upgrade from v9.6 a disaster
  • From: Andrew Dunstan
• AWS forcing PG upgrade from v9.6 a disaster
  • From: Dean Gibson (DB Administrator)
• Re: transaction blocking on COMMIT
  • From: Bob Jolliffe
• Count (select 1) subquery as constant
  • From: Eugen Konkov
• Re: issue partition scan
  • From: Christophe Pettus
• Re: issue partition scan
  • From: David Rowley
• Re: issue partition scan
  • From: Nagaraj Raj
• Re: issue partition scan
  • From: Christophe Pettus
• issue partition scan
  • From: Nagaraj Raj
• Re: transaction blocking on COMMIT
  • From: Alexey M Boltenkov
• Re: transaction blocking on COMMIT
  • From: Christophe Pettus
• Re: transaction blocking on COMMIT
  • From: Bob Jolliffe
• Re: Optimising outer joins in the presence of non-nullable references
  • From: Tom Lane
• Re: transaction blocking on COMMIT
  • From: Vijaykumar Jain
• Re: transaction blocking on COMMIT
  • From: Bob Jolliffe
• Optimising outer joins in the presence of non-nullable references
  • From: Philip Lykke Carlsen
• Re: transaction blocking on COMMIT
  • From: Vijaykumar Jain
• transaction blocking on COMMIT
  • From: Bob Jolliffe
• RE: Partition with check constraint with "like"
  • From: Michel SALAIS
• Re: Partition with check constraint with "like"
  • From: David Rowley
• Re: Partition with check constraint with "like"
  • From: David Rowley
• Re: Partition with check constraint with "like"
  • From: Nagaraj Raj
• Re: Partition with check constraint with "like"
  • From: Nagaraj Raj
• RE: Partition with check constraint with "like"
  • From: Michel SALAIS
• Re: Partition with check constraint with "like"
  • From: Nagaraj Raj
• Re: Partition with check constraint with "like"
  • From: Vijaykumar Jain
• Re: Partition with check constraint with "like"
  • From: Nagaraj Raj
• Re: logical replication
  • From: Marc Millas
• Re: logical replication
  • From: Andrew Dunstan
• logical replication
  • From: Marc Millas
• Re: Partition with check constraint with "like"
  • From: David Rowley
• Re: Partition with check constraint with "like"
  • From: Nagaraj Raj
• Re: Partition with check constraint with "like"
  • From: Michael Lewis
• Re: Partition with check constraint with "like"
  • From: Justin Pryzby
• Re: Partition with check constraint with "like"
  • From: Nagaraj Raj
• Re: Partition with check constraint with "like"
  • From: David Rowley
• Partition with check constraint with "like"
  • From: Nagaraj Raj
• Re: Index and statistics not used
  • From: David Rowley
• Index and statistics not used
  • From: rstander
• Re: BUG #16968: Planner does not recognize optimization
  • From: Eugen Konkov
• Re: BUG #16968: Planner does not recognize optimization
  • From: Eugen Konkov
• Re: BUG #16968: Planner does not recognize optimization
  • From: David Rowley
• Re: BUG #16968: Planner does not recognize optimization
  • From: David Rowley
• Re: BUG #16968: Planner does not recognize optimization
  • From: Eugen Konkov
• Re: Very slow "bloat query"
  • From: Marcin Gozdalik
• Re: Very slow "bloat query"
  • From: Marcin Gozdalik
• Re: Very slow "bloat query"
  • From: Imre Samu
• Re: BUG #16968: Planner does not recognize optimization
  • From: KES
• Re: Very slow "bloat query"
  • From: Marcin Gozdalik
• Re: Very slow "bloat query"
  • From: Tom Lane
• Re: Very slow "bloat query"
  • From: Imre Samu
• Re: Very slow "bloat query"
  • From: Gilles Darold
• Very slow "bloat query"
  • From: Marcin Gozdalik
• RE: Re: PostgreSQL blocked locks query
  • From: Manoj Kumar
• Re: BUG #16968: Planner does not recognize optimization
  • From: David Rowley
• Re: PostgreSQL blocked locks query
  • From: Justin Pryzby
• PostgreSQL blocked locks query
  • From: Manoj Kumar
• Re: Very slow Query compared to Oracle / SQL - Server
  • From: Semen Yefimenko
• Re: Very slow Query compared to Oracle / SQL - Server
  • From: Semen Yefimenko
• Re: Very slow Query compared to Oracle / SQL - Server
  • From: didier
• Re: Very slow Query compared to Oracle / SQL - Server
  • From: Peter Geoghegan
• Re: Very slow Query compared to Oracle / SQL - Server
  • From: Peter Geoghegan
• Re: Very slow Query compared to Oracle / SQL - Server
  • From: Tom Lane
• Re: Very slow Query compared to Oracle / SQL - Server
  • From: Justin Pryzby
• Re: Very slow Query compared to Oracle / SQL - Server
  • From: Semen Yefimenko
• Re: Very slow Query compared to Oracle / SQL - Server
  • From: Rick Otten
• Re: Very slow Query compared to Oracle / SQL - Server
  • From: Vijaykumar Jain
• Re: Very slow Query compared to Oracle / SQL - Server
  • From: Semen Yefimenko
• Re: Very slow Query compared to Oracle / SQL - Server
  • From: Vijaykumar Jain
• Re: Very slow Query compared to Oracle / SQL - Server
  • From: Semen Yefimenko
• Re: Very slow Query compared to Oracle / SQL - Server
  • From: Imre Samu
• Re: Very slow Query compared to Oracle / SQL - Server
  • From: Alexey M Boltenkov
• Re: Very slow Query compared to Oracle / SQL - Server
  • From: Alexey M Boltenkov
• Re: Very slow Query compared to Oracle / SQL - Server
  • From: Justin Pryzby
• Re: Very slow Query compared to Oracle / SQL - Server
  • From: Alexey M Boltenkov
• Re: Very slow Query compared to Oracle / SQL - Server
  • From: Vijaykumar Jain
• Re: Very slow Query compared to Oracle / SQL - Server
  • From: Andreas Joseph Krogh
• Re: Very slow Query compared to Oracle / SQL - Server
  • From: Semen Yefimenko
• Re: Very slow Query compared to Oracle / SQL - Server
  • From: Alexey M Boltenkov
• Re: Very slow Query compared to Oracle / SQL - Server
  • From: Alexey M Boltenkov
• Re: Very slow Query compared to Oracle / SQL - Server
  • From: luis . roberto
• Very slow Query compared to Oracle / SQL - Server
  • From: Semen Yefimenko
• Re: 15x slower PreparedStatement vs raw query
  • From: Alex
• Re: 15x slower PreparedStatement vs raw query
  • From: Justin Pryzby
• Re: 15x slower PreparedStatement vs raw query
  • From: David Rowley
• Re: 15x slower PreparedStatement vs raw query
  • From: Vijaykumar Jain
• Re: 15x slower PreparedStatement vs raw query
  • From: Laurenz Albe
• Re: 15x slower PreparedStatement vs raw query
  • From: Alex
• Re: 15x slower PreparedStatement vs raw query
  • From: Rick Otten
• Re: 15x slower PreparedStatement vs raw query
  • From: Alex
• Re: 15x slower PreparedStatement vs raw query
  • From: Justin Pryzby
• 15x slower PreparedStatement vs raw query
  • From: Alex
• Re: Error while calling proc with table type from Application (npgsql)
  • From: Vijaykumar Jain
• Re: Error while calling proc with table type from Application (npgsql)
  • From: aditya desai
• Re: Error while calling proc with table type from Application (npgsql)
  • From: aditya desai
• RES: Log number of tuples returned
  • From: Edson Richter
• Re: Log number of tuples returned
  • From: Justin Pryzby
• Log number of tuples returned
  • From: Edson Richter
• Re: Error while calling proc with table type from Application (npgsql)
  • From: Justin Pryzby
• Error while calling proc with table type from Application
  • From: aditya desai
• Re: Order of execution
  • From: Jean-Christophe Boggio
• Order of execution
  • From: luis . roberto
• Re: Does btrfs on Linux have a negative performance impact for PostgreSQL 13?
  • From: Marc Millas
• Re: Does btrfs on Linux have a negative performance impact for PostgreSQL 13?
  • From: Rory Campbell-Lange
• Re: Does btrfs on Linux have a negative performance impact for PostgreSQL 13?
  • From: Marc Millas
• Re: Does btrfs on Linux have a negative performance impact for PostgreSQL 13?
  • From: Simon Connah
• Re: Does btrfs on Linux have a negative performance impact for PostgreSQL 13?
  • From: Rory Campbell-Lange
• Re: Does btrfs on Linux have a negative performance impact for PostgreSQL 13?
  • From: Tomas Vondra
• Re: Does btrfs on Linux have a negative performance impact for PostgreSQL 13?
  • From: Christophe Pettus
• Re: Does btrfs on Linux have a negative performance impact for PostgreSQL 13?
  • From: Bruce Momjian
• Re: Does btrfs on Linux have a negative performance impact for PostgreSQL 13?
  • From: Justin Pryzby
• Does btrfs on Linux have a negative performance impact for PostgreSQL 13?
  • From: Simon Connah
• Re: hint in determining effective_io_concurrency
  • From: Bruce Momjian
• Re: hint in determining effective_io_concurrency
  • From: Justin Pryzby
• Re: hint in determining effective_io_concurrency
  • From: Luca Ferrari
• Re: hint in determining effective_io_concurrency
  • From: Justin Pryzby
• Re: hint in determining effective_io_concurrency
  • From: Bruce Momjian
• Re: hint in determining effective_io_concurrency
  • From: Luca Ferrari
• Re: hint in determining effective_io_concurrency
  • From: Bruce Momjian
• hint in determining effective_io_concurrency
  • From: Luca Ferrari
• Re: Planning performance problem (67626.278ms)
  • From: Tom Lane
• Re: Planning performance problem (67626.278ms)
  • From: David Rowley
• Re: Planning performance problem (67626.278ms)
  • From: Jeremy Schneider
• Re: OLEDB for PostgreSQL
  • From: Pavan Pusuluri
• Re: OLEDB for PostgreSQL
  • From: aditya desai
• Re: Most proper partitioning form on an integer column
  • From: Justin Pryzby
• Most proper partitioning form on an integer column
  • From: Il Mimo di Creta
• Re: Disabling options lowers the estimated cost of a query
  • From: Tomas Vondra
• Re: Why is there a tenfold difference between Postgres's alleged query execution time and packet transmission time?
  • From: Tom Lane
• Re: Disabling options lowers the estimated cost of a query
  • From: Tom Lane
• Re: Disabling options lowers the estimated cost of a query
  • From: Tom Lane
• Re: Strange behavior once statistics are there
  • From: Daniel Westermann (DWE)
• Re: Disabling options lowers the estimated cost of a query
  • From: Tomas Vondra
• Re: Disabling options lowers the estimated cost of a query
  • From: Arne Roland
• Re: Strange behavior once statistics are there
  • From: Tom Lane
• Re: Is there a way to change current time?
  • From: Eugene Pazhitnov
• Re: Is there a way to change current time?
  • From: Pavel Stehule
• Re: Is there a way to change current time?
  • From: Tom Lane
• Re: Is there a way to change current time?
  • From: Justin Pryzby
• Re: Is there a way to change current time?
  • From: Bruce Momjian
• Is there a way to change current time?
  • From: Warstone@list.ru
• Strange behavior once statistics are there
  • From: Daniel Westermann (DWE)
• Why is there a tenfold difference between Postgres's alleged query execution time and packet transmission time?
  • From: Rollo Konig-Brock
• Re: LWLocks by LockManager slowing large DB
  • From: Alvaro Herrera
• Re: LWLocks by LockManager slowing large DB
  • From: Andres Freund
• Re: LWLocks by LockManager slowing large DB
  • From: Tom Lane
• Re: LWLocks by LockManager slowing large DB
  • From: Andres Freund
• Re: LWLocks by LockManager slowing large DB
  • From: Tom Lane
• RE: LWLocks by LockManager slowing large DB
  • From: Paul Friedman
• Re: LWLocks by LockManager slowing large DB
  • From: Tom Lane
• Re: LWLocks by LockManager slowing large DB
  • From: Alvaro Herrera
• Re: LWLocks by LockManager slowing large DB
  • From: Andres Freund
• RE: LWLocks by LockManager slowing large DB
  • From: Paul Friedman
• Re: LWLocks by LockManager slowing large DB
  • From: Andres Freund
• RE: LWLocks by LockManager slowing large DB
  • From: Paul Friedman
• RE: LWLocks by LockManager slowing large DB
  • From: Paul Friedman
• Re: LWLocks by LockManager slowing large DB
  • From: Nikolay Samokhvalov
• Re: LWLocks by LockManager slowing large DB
  • From: Andres Freund
• RE: LWLocks by LockManager slowing large DB
  • From: Paul Friedman
• Re: LWLocks by LockManager slowing large DB
  • From: Andres Freund
• RE: LWLocks by LockManager slowing large DB
  • From: Paul Friedman
• Re: LWLocks by LockManager slowing large DB
  • From: Andres Freund
• LWLocks by LockManager slowing large DB
  • From: Paul Friedman
• Re: INSERTS waiting with wait_event is "transactionid"
  • From: Nagaraj Raj
• Re: INSERTS waiting with wait_event is "transactionid"
  • From: Laurenz Albe
• INSERTS waiting with wait_event is "transactionid"
  • From: Nagaraj Raj
• RE: procedure using CURSOR to insert is extremely slow
  • From: Szalontai Zoltán
• Re: procedure using CURSOR to insert is extremely slow
  • From: Milos Babic
• RE: procedure using CURSOR to insert is extremely slow
  • From: Mike Sofen
• RE: procedure using CURSOR to insert is extremely slow
  • From: Szalontai Zoltán
• Re: str_aggr function not wokring
  • From: aditya desai
• Re: str_aggr function not wokring
  • From: aditya desai
• Re: procedure using CURSOR to insert is extremely slow
  • From: Milos Babic
• RE: procedure using CURSOR to insert is extremely slow
  • From: Szalontai Zoltán
• RE: str_aggr function not wokring
  • From: Patrick FICHE
• Re: procedure using CURSOR to insert is extremely slow
  • From: Hervé Schweitzer (HER)
• str_aggr function not wokring
  • From: aditya desai
• procedure using CURSOR to insert is extremely slow
  • From: Szalontai Zoltán
• Re: select count(*) is slow
  • From: aditya desai
• Re: SHARED LOCKS , EXCLUSIVE LOCKS, ACCESS EXCLUSIVE LOCKS
  • From: Andrew Dunstan
• Re: select count(*) is slow
  • From: Andrew Dunstan
• Re: select count(*) is slow
  • From: aditya desai
• Re: select count(*) is slow
  • From: Tom Lane
• Re: Substitute for synonym in Oracle after migration to postgres
  • From: aditya desai
• select count(*) is slow
  • From: aditya desai
• Re: Substitute for synonym in Oracle after migration to postgres
  • From: hubert depesz lubaczewski
• Re: Substitute for synonym in Oracle after migration to postgres
  • From: Laurenz Albe
• Substitute for synonym in Oracle after migration to postgres
  • From: aditya desai
• Re: SHARED LOCKS , EXCLUSIVE LOCKS, ACCESS EXCLUSIVE LOCKS
  • From: aditya desai
• PosgtgreSQL hot standby reading WAL from muli-attached volume?
  • From: Gunther Schadow
• Re: SHARED LOCKS , EXCLUSIVE LOCKS, ACCESS EXCLUSIVE LOCKS
  • From: Justin Pryzby
• Re: SHARED LOCKS , EXCLUSIVE LOCKS, ACCESS EXCLUSIVE LOCKS
  • From: Amine Tengilimoglu
• Re: SELECT Query taking 200 ms on PostgreSQL compared to 4 ms on Oracle after migration.
  • From: aditya desai
• SHARED LOCKS , EXCLUSIVE LOCKS, ACCESS EXCLUSIVE LOCKS
  • From: aditya desai
• Re: SELECT Query taking 200 ms on PostgreSQL compared to 4 ms on Oracle after migration.
  • From: Pavel Stehule
• Re: SELECT Query taking 200 ms on PostgreSQL compared to 4 ms on Oracle after migration.
  • From: aditya desai
• Re: SELECT Query taking 200 ms on PostgreSQL compared to 4 ms on Oracle after migration.
  • From: Pavel Stehule
• Re: SELECT Query taking 200 ms on PostgreSQL compared to 4 ms on Oracle after migration.
  • From: aditya desai
• Re: SELECT Query taking 200 ms on PostgreSQL compared to 4 ms on Oracle after migration.
  • From: aditya desai
• Re: SELECT Query taking 200 ms on PostgreSQL compared to 4 ms on Oracle after migration.
  • From: Bruce Momjian
• Re: SELECT Query taking 200 ms on PostgreSQL compared to 4 ms on Oracle after migration.
  • From: Bruce Momjian
• Re: SELECT Query taking 200 ms on PostgreSQL compared to 4 ms on Oracle after migration.
  • From: Justin Pryzby
• Re: SELECT Query taking 200 ms on PostgreSQL compared to 4 ms on Oracle after migration.
  • From: Tom Lane
• Re: SELECT Query taking 200 ms on PostgreSQL compared to 4 ms on Oracle after migration.
  • From: Bruce Momjian
• Re: SELECT Query taking 200 ms on PostgreSQL compared to 4 ms on Oracle after migration.
  • From: Pavel Stehule
• Re: SELECT Query taking 200 ms on PostgreSQL compared to 4 ms on Oracle after migration.
  • From: aditya desai
• Re: SELECT Query taking 200 ms on PostgreSQL compared to 4 ms on Oracle after migration.
  • From: aditya desai
• Re: SELECT Query taking 200 ms on PostgreSQL compared to 4 ms on Oracle after migration.
  • From: Bruce Momjian
• Re: SELECT Query taking 200 ms on PostgreSQL compared to 4 ms on Oracle after migration.
  • From: aditya desai
• Re: SELECT Query taking 200 ms on PostgreSQL compared to 4 ms on Oracle after migration.
  • From: Bruce Momjian
• Re: SELECT Query taking 200 ms on PostgreSQL compared to 4 ms on Oracle after migration.
  • From: aditya desai
• Re: SELECT Query taking 200 ms on PostgreSQL compared to 4 ms on Oracle after migration.
  • From: Bruce Momjian
• Re: SELECT Query taking 200 ms on PostgreSQL compared to 4 ms on Oracle after migration.
  • From: aditya desai
• Re: SELECT Query taking 200 ms on PostgreSQL compared to 4 ms on Oracle after migration.
  • From: Justin Pryzby
• Re: SELECT Query taking 200 ms on PostgreSQL compared to 4 ms on Oracle after migration.
  • From: Michael Lewis
• Re: SELECT Query taking 200 ms on PostgreSQL compared to 4 ms on Oracle after migration.
  • From: Pavel Stehule
• Re: SELECT Query taking 200 ms on PostgreSQL compared to 4 ms on Oracle after migration.
  • From: Bharath Rupireddy
• SELECT Query taking 200 ms on PostgreSQL compared to 4 ms on Oracle after migration.
  • From: aditya desai
• Re: High availability management tool.
  • From: Adalberto Caccia
• Re: High availability management tool.
  • From: Hüseyin Demir
• Re: High availability management tool.
  • From: Dorian Hoxha
• Re: High-volume writes - what is the max throughput possible
  • From: Hannu Krosing
• Re: High-volume writes - what is the max throughput possible
  • From: Frits Jalvingh
• High-volume writes - what is the max throughput possible
  • From: Geervan Hayatnagarkar
• Re: How do we hint a query to use index in postgre
  • From: Nikhil Shetty
• Re: Odd (slow) plan choice with min/max
  • From: Yoan SULTAN
• Re: SQL performance issue (postgresql chooses a bad plan when a better one is available)
  • From: Hannu Krosing
• Re: Odd (slow) plan choice with min/max
  • From: Paul McGarry
• Re: SQL performance issue (postgresql chooses a bad plan when a better one is available)
  • From: Chris Stephens
• Re: Odd (slow) plan choice with min/max
  • From: Rick Otten
• Re: Odd (slow) plan choice with min/max
  • From: Paul McGarry
• Re: Odd (slow) plan choice with min/max
  • From: Justin Pryzby
• Odd (slow) plan choice with min/max
  • From: Paul McGarry
• Re: SQL performance issue (postgresql chooses a bad plan when a better one is available)
  • From: Hannu Krosing
• Re: SQL performance issue (postgresql chooses a bad plan when a better one is available)
  • From: Chris Stephens
• Re: SQL performance issue (postgresql chooses a bad plan when a better one is available)
  • From: Laurenz Albe
• SQL performance issue (postgresql chooses a bad plan when a better one is available)
  • From: Chris Stephens
• Re: How do we hint a query to use index in postgre
  • From: Manish Lad
• Re: How do we hint a query to use index in postgre
  • From: Gaetano Mendola
• How do we hint a query to use index in postgre
  • From: Manish Lad
• Re: Extremely inefficient merge-join
  • From: Marcin Gozdalik
• Re: Extremely inefficient merge-join
  • From: Tom Lane
• Extremely inefficient merge-join
  • From: Marcin Gozdalik
• Re: wide table, many many partitions, poor query performance
  • From: Laurenz Albe
• Re: wide table, many many partitions, poor query performance
  • From: Justin Pryzby
• wide table, many many partitions, poor query performance
  • From: S Bob
• Re: FreeBSD UFS & fsync
  • From: Luca Ferrari
• Re: FreeBSD UFS & fsync
  • From: Bruce Momjian
• Re: Is there a known bug with SKIP LOCKED and "tuple to be locked was already moved to another partition due to concurrent update"?
  • From: Kamil Dziedzic
• Re: Is there a known bug with SKIP LOCKED and "tuple to be locked was already moved to another partition due to concurrent update"?
  • From: Michael Lewis
• Re: Fwd: different execution time for the same query (and same DB status)
  • From: Francesco De Angelis
• Re: FreeBSD UFS & fsync
  • From: Thomas Munro
• Re: FreeBSD UFS & fsync
  • From: Luca Ferrari
• Re: Is there a known bug with SKIP LOCKED and "tuple to be locked was already moved to another partition due to concurrent update"?
  • From: Kamil Dziedzic
• Re: FreeBSD UFS & fsync
  • From: Bruce Momjian
• Re: Fwd: different execution time for the same query (and same DB status)
  • From: Francesco De Angelis
• Re: Fwd: different execution time for the same query (and same DB status)
  • From: Michael Lewis
• Re: Fwd: different execution time for the same query (and same DB status)
  • From: Justin Pryzby
• Re: different execution time for the same query (and same DB status)
  • From: Francesco De Angelis
• Re: Users grants with setting options
  • From: Nagaraj Raj
• Re: Users grants with setting options
  • From: David G. Johnston
• Users grants with setting options
  • From: Nagaraj Raj
• Re: different execution time for the same query (and same DB status)
  • From: Michael Lewis
• Re: Slow query performance inside a transaction on a clean database
  • From: Laurenz Albe
• Re: different execution time for the same query (and same DB status)
  • From: Tom Lane
• Re: different execution time for the same query (and same DB status)
  • From: Julien Rouhaud
• RE: different execution time for the same query (and same DB status)
  • From: Michel SALAIS
• Fwd: different execution time for the same query (and same DB status)
  • From: Francesco De Angelis
• Slow query performance inside a transaction on a clean database
  • From: val.janeiko
• Re: Potential performance issues related to group by and covering index
  • From: Hannu Krosing
• Re: tables meta data collection
  • From: Justin Pryzby
• tables meta data collection
  • From: Nagaraj Raj
• Re: Potential performance issues related to group by and covering index
  • From: David Rowley
• Re: Potential performance issues related to group by and covering index
  • From: Michael Lewis
• High availability management tool.
  • From: Rodriguez Pablo A
• Re: Performance issues related to left join and order by
  • From: David Rowley
• Re: Potential performance issues related to group by and covering index
  • From: David Rowley
• Re: Potential performance issues related to group by and covering index
  • From: Pavel Stehule
• Performance issues related to left join and order by
  • From: Liu, Xinyu
• Potential performance issues related to group by and covering index
  • From: Liu, Xinyu
• Re: Potential performance issues
  • From: Hannu Krosing
• Re: Postgres performance comparing GCP and AWS
  • From: Hannu Krosing
• Re: Potential performance issues
  • From: Pavel Stehule
• Re: Potential performance issues
  • From: Jung, Jinho
• Re: Potential performance issues
  • From: Rick Otten
• Re: Potential performance issues
  • From: Thomas Kellerer
• Re: Potential performance issues
  • From: Bob Jolliffe
• Re: Potential performance issues
  • From: MichaelDBA
• Re: Potential performance issues
  • From: MichaelDBA
• Re: Potential performance issues
  • From: Andrew Dunstan
• Potential performance issues
  • From: Jung, Jinho
• Re: Postgres performance comparing GCP and AWS
  • From: Justin Pitts
• Re: Postgres performance comparing GCP and AWS
  • From: Igor Gois
• Re: Postgres performance comparing GCP and AWS
  • From: Igor Gois
• Re: Disabling options lowers the estimated cost of a query
  • From: Tom Lane
• Disabling options lowers the estimated cost of a query
  • From: Arne Roland
• Re: Postgres performance comparing GCP and AWS
  • From: Philip Semanchuk
• Re: Postgres performance comparing GCP and AWS
  • From: Philip Semanchuk
• Re: Postgres performance comparing GCP and AWS
  • From: Philip Semanchuk
• Re: Postgres performance comparing GCP and AWS
  • From: Igor Gois
• Re: Postgres performance comparing GCP and AWS
  • From: Imre Samu
• Re: Postgres performance comparing GCP and AWS
  • From: Julien Rouhaud
• Re: Postgres performance comparing GCP and AWS
  • From: Milos Babic
• Re: Postgres performance comparing GCP and AWS
  • From: Gunther Schadow
• Postgres performance comparing GCP and AWS
  • From: Maurici Meneghetti
• Re: FreeBSD UFS & fsync
  • From: Luca Ferrari
• Re: FreeBSD UFS & fsync
  • From: Luca Ferrari
• Re: FreeBSD UFS & fsync
  • From: Thomas Munro
• FreeBSD UFS & fsync
  • From: Luca Ferrari
• Re: Autovacuum not functioning for large tables but it is working for few other small tables.
  • From: Laurenz Albe
• RE: Autovacuum not functioning for large tables but it is working for few other small tables.
  • From: M Tarkeshwar Rao
• Re: Slow query and wrong row estimates for CTE
  • From: Yoan SULTAN
• Re: Slow query and wrong row estimates for CTE
  • From: Dane Foster
• Re: Slow query and wrong row estimates for CTE
  • From: Yoan SULTAN
• Re: Slow query and wrong row estimates for CTE
  • From: Dane Foster
• Re: Slow query and wrong row estimates for CTE
  • From: Dane Foster
• Re: Query performance issue
  • From: Michael Lewis
• Re: Slow query and wrong row estimates for CTE
  • From: Dane Foster
• Re: Slow query and wrong row estimates for CTE
  • From: Dane Foster
• Re: Slow query and wrong row estimates for CTE
  • From: Michael Lewis
• Re: Slow query and wrong row estimates for CTE
  • From: Justin Pryzby
• Slow query and wrong row estimates for CTE
  • From: Dane Foster
• Re: Query performance issue
  • From: Tomas Vondra
• Re: Query performance issue
  • From: Justin Pryzby
• Query performance issue
  • From: Nagaraj Raj
• Understanding logical replication lag
  • From: Patrick Molgaard
• Re: High COMMIT times
  • From: Don Seiler
• RE: Need information on how MM frees up disk space (vaccum) after scheduled DB cleanup by BGwCronScript/BGwLogCleaner
  • From: M Tarkeshwar Rao
• Re: How to deal with analyze gathering irrelevant stats
  • From: Michael Lewis
• Re: How to deal with analyze gathering irrelevant stats
  • From: Rémi Chatenay
• Re: How to deal with analyze gathering irrelevant stats
  • From: Michael Lewis
• Re: How to deal with analyze gathering irrelevant stats
  • From: Adam Brusselback
• Re: How to deal with analyze gathering irrelevant stats
  • From: Justin Pryzby
• How to deal with analyze gathering irrelevant stats
  • From: Rémi Chatenay
• Re: High COMMIT times
  • From: Don Seiler
• Re: High COMMIT times
  • From: Craig Jackson
• Re: High COMMIT times
  • From: Don Seiler
• Re: High COMMIT times
  • From: Jeff Janes
• Re: High COMMIT times
  • From: Craig Jackson
• Re: High COMMIT times
  • From: Don Seiler
• Re: High COMMIT times
  • From: José Arthur Benetasso Villanova
• Re: Autovacuum not functioning for large tables but it is working for few other small tables.
  • From: Michael Lewis
• RE: Autovacuum not functioning for large tables but it is working for few other small tables.
  • From: M Tarkeshwar Rao
• Re: High COMMIT times
  • From: Laurenz Albe
• Re: High COMMIT times
  • From: Don Seiler
• Re: High COMMIT times
  • From: Craig Jackson
• Re: High COMMIT times
  • From: Laurenz Albe
• Re: High COMMIT times
  • From: Don Seiler
• Re: High COMMIT times
  • From: Kenneth Marshall
• Re: High COMMIT times
  • From: Joshua Drake
• Re: High COMMIT times
  • From: Don Seiler
• Re: High COMMIT times
  • From: Joshua Drake
• High COMMIT times
  • From: Don Seiler
• Re: Slow recursive CTE query questions, with row estimate and n_distinct issues
  • From: Christopher Baines
• Re: Slow recursive CTE query questions, with row estimate and n_distinct issues
  • From: Christopher Baines
• Re: Slow recursive CTE query questions, with row estimate and n_distinct issues
  • From: Greg Spiegelberg
• Re: Slow recursive CTE query questions, with row estimate and n_distinct issues
  • From: Michael Lewis
• Slow recursive CTE query questions, with row estimate and n_distinct issues
  • From: Christopher Baines
• Re: Conundrum with scaling out of bottleneck with hot standby, PgPool-II, etc.
  • From: Bruce Momjian
• Re: Conundrum with scaling out of bottleneck with hot standby, PgPool-II, etc.
  • From: Marco Colli
• Conundrum with scaling out of bottleneck with hot standby, PgPool-II, etc.
  • From: Gunther Schadow
• Re: Reversing NULLS in ORDER causes index not to be used?
  • From: Ken Tanzer
• Re: Reversing NULLS in ORDER causes index not to be used?
  • From: Tom Lane
• Reversing NULLS in ORDER causes index not to be used?
  • From: Ken Tanzer
• Re: Oracle to postgresql
  • From: Ian Lawrence Barwick
• Oracle to postgresql
  • From: bangalore umesh
• Re: Autovacuum not functioning for large tables but it is working for few other small tables.
  • From: Tomas Vondra
• RE: Autovacuum not functioning for large tables but it is working for few other small tables.
  • From: M Tarkeshwar Rao
• Performance issues with composite types (partitioned table)
  • From: Sebastijan Wieser
• Re: "Required checkpoints occurs too frequently"
  • From: Laurenz Albe
• Re: "Required checkpoints occurs too frequently"
  • From: Atul Kumar
• "Required checkpoints occurs too frequently"
  • From: Atul Kumar
• Re: "Required checkpoints occurs too frequently"
  • From: Amine Tengilimoglu
• Re: "Required checkpoints occurs too frequently"
  • From: Christophe Pettus
• Re: "Required checkpoints occurs too frequently"
  • From: Atul Kumar
• Re: Index for range queries on JSON (user defined fields)
  • From: Marco Colli
• Re: Index for range queries on JSON (user defined fields)
  • From: Nick Cleaton
• Re: PostgeSQL JSONB Column with various type of data
  • From: Michael Lewis
• PostgeSQL JSONB Column with various type of data
  • From: Riswana Rahman
• Index for range queries on JSON (user defined fields)
  • From: Marco Colli
• Re: Pg_locks and pg_stat_activity
  • From: aditya desai
• Re: Pg_locks and pg_stat_activity
  • From: Justin Pryzby
• Re: Pg_locks and pg_stat_activity
  • From: aditya desai
• Re: Pg_locks and pg_stat_activity
  • From: aditya desai
• Re: Pg_locks and pg_stat_activity
  • From: Kyotaro Horiguchi
• Re: Pg_locks and pg_stat_activity
  • From: Justin Pryzby
• Re: Pg_locks and pg_stat_activity
  • From: Ravikumar Reddy
• Re: Pg_locks and pg_stat_activity
  • From: aditya desai
• Re: Temporarily disable not null constraints
  • From: Justin Pryzby
• Re: Temporarily disable not null constraints
  • From: Milos Babic
• Re: Temporarily disable not null constraints
  • From: Michael Lewis
• Temporarily disable not null constraints
  • From: Nagaraj Raj
• Re: time taking deletion on large tables
  • From: Andrew Dunstan
• Re: time taking deletion on large tables
  • From: Tom Lane
• Re: time taking deletion on large tables
  • From: Justin Pryzby
• Re: time taking deletion on large tables
  • From: Ravikumar Reddy
• time taking deletion on large tables
  • From: Atul Kumar
• Re: Pg_locks and pg_stat_activity
  • From: aditya desai
• Pg_locks and pg_stat_activity
  • From: aditya desai
• Re: Simple update query is slow
  • From: Justin Pryzby
• Re: Simple update query is slow
  • From: Nandakumar M
• Simple update query is slow
  • From: Nandakumar M
• Re: How to prioritise walsender reading from pg_wal over WAL writes?
  • From: Alexey Bashtanov
• Re: Postgres using nested loops despite setting enable_nestloop to false
  • From: Frits Jalvingh
• Re: How to prioritise walsender reading from pg_wal over WAL writes?
  • From: Laurenz Albe
• Re: How to prioritise walsender reading from pg_wal over WAL writes?
  • From: Alexey Bashtanov
• Re: How to prioritise walsender reading from pg_wal over WAL writes?
  • From: Laurenz Albe
• Re: How to prioritise walsender reading from pg_wal over WAL writes?
  • From: Alexey Bashtanov
• Re: Postgres using nested loops despite setting enable_nestloop to false
  • From: Frits Jalvingh
• Re: Postgres using nested loops despite setting enable_nestloop to false
  • From: Tom Lane
• Re: Postgres using nested loops despite setting enable_nestloop to false
  • From: Frits Jalvingh
• Re: Postgres using nested loops despite setting enable_nestloop to false
  • From: Frits Jalvingh
• Re: Postgres using nested loops despite setting enable_nestloop to false
  • From: Justin Pryzby
• Re: Postgres using nested loops despite setting enable_nestloop to false
  • From: Frits Jalvingh
• Re: Postgres using nested loops despite setting enable_nestloop to false
  • From: Justin Pryzby
• Install clustered postgres
  • From: Nunzia Vairo
• Postgres using nested loops despite setting enable_nestloop to false
  • From: Frits Jalvingh
• How to prioritise walsender reading from pg_wal over WAL writes?
  • From: Alexey Bashtanov
• RE: Partition pruning with joins
  • From: Ehrenreich, Sigrid
• Re: Adding nextval() to a select caused hang/very slow execution
  • From: Eric Raskin
• Re: Low cost query - running longer
  • From: David G. Johnston
• Low cost query - running longer
  • From: Koteswara Rao Daliparthi
• Re: Adding nextval() to a select caused hang/very slow execution
  • From: Tom Lane
• Re: Adding nextval() to a select caused hang/very slow execution
  • From: Eric Raskin
• Re: Adding nextval() to a select caused hang/very slow execution
  • From: Michael Lewis
• Re: Partition pruning with joins
  • From: David Rowley
• Re: Adding nextval() to a select caused hang/very slow execution
  • From: Tom Lane
• Re: Adding nextval() to a select caused hang/very slow execution
  • From: Eric Raskin
• Re: Adding nextval() to a select caused hang/very slow execution
  • From: Tom Lane
• Re: Adding nextval() to a select caused hang/very slow execution
  • From: Eric Raskin
• Re: Adding nextval() to a select caused hang/very slow execution
  • From: Tom Lane
• Re: Adding nextval() to a select caused hang/very slow execution
  • From: Eric Raskin
• Re: Adding nextval() to a select caused hang/very slow execution
  • From: Eric Raskin
• Re: Adding nextval() to a select caused hang/very slow execution
  • From: Tom Lane
• RE: Adding nextval() to a select caused hang/very slow execution
  • From: Eric Raskin
• Adding nextval() to a select caused hang/very slow execution
  • From: Eric Raskin
• RE: Partition pruning with joins
  • From: Ehrenreich, Sigrid
• Re: Partition pruning with joins
  • From: Laurenz Albe
• Re: Understanding bad estimate (related to FKs?)
  • From: Philip Semanchuk
• Re: Understanding bad estimate (related to FKs?)
  • From: Philip Semanchuk
• Partition pruning with joins
  • From: Ehrenreich, Sigrid
• Re: Understanding bad estimate (related to FKs?)
  • From: Tomas Vondra
• Re: Understanding bad estimate (related to FKs?)
  • From: Michael Lewis
• Re: Understanding bad estimate (related to FKs?)
  • From: Guillaume Lelarge
• Re: Understanding bad estimate (related to FKs?)
  • From: Tom Lane
• Re: Understanding bad estimate (related to FKs?)
  • From: Justin Pryzby
• Re: Understanding bad estimate (related to FKs?)
  • From: Philip Semanchuk
• Re: Understanding bad estimate (related to FKs?)
  • From: Guillaume Lelarge
• Re: Understanding bad estimate (related to FKs?)
  • From: Philip Semanchuk
• Re: Understanding bad estimate (related to FKs?)
  • From: Tomas Vondra
• Re: Understanding bad estimate (related to FKs?)
  • From: Philip Semanchuk
• Re: query plan using partial index expects a much larger number of rows than is possible
  • From: Michael Lewis
• RE: Postgres Optimizer ignores information about foreign key relationship, severly misestimating number of returned rows in join
  • From: Ehrenreich, Sigrid
• Re: Postgres Optimizer ignores information about foreign key relationship, severly misestimating number of returned rows in join
  • From: Magnus Hagander
• RE: Postgres Optimizer ignores information about foreign key relationship, severly misestimating number of returned rows in join
  • From: Ehrenreich, Sigrid
• Re: Understanding bad estimate (related to FKs?)
  • From: Justin Pryzby
• Re: query plan using partial index expects a much larger number of rows than is possible
  • From: Olivier Poquet
• Re: query plan using partial index expects a much larger number of rows than is possible
  • From: Tom Lane
• query plan using partial index expects a much larger number of rows than is possible
  • From: Olivier Poquet
• Re: Postgres Optimizer ignores information about foreign key relationship, severly misestimating number of returned rows in join
  • From: Tom Lane
• Re: Query Performance / Planner estimate off
  • From: Mats Olsen
• RE: Postgres Optimizer ignores information about foreign key relationship, severly misestimating number of returned rows in join
  • From: Ehrenreich, Sigrid
• Re: Postgres Optimizer ignores information about foreign key relationship, severly misestimating number of returned rows in join
  • From: Tom Lane
• Re: Postgres Optimizer ignores information about foreign key relationship, severly misestimating number of returned rows in join
  • From: David Rowley
• Re: Postgres Optimizer ignores information about foreign key relationship, severely misestimating number of returned rows in join
  • From: Justin Pryzby
• Re: Understanding bad estimate (related to FKs?)
  • From: Philip Semanchuk
• Postgres Optimizer ignores information about foreign key relationship, severly misestimating number of returned rows in join
  • From: Ehrenreich, Sigrid
• Re: Understanding bad estimate (related to FKs?)
  • From: Michael Lewis
• Re: Understanding bad estimate (related to FKs?)
  • From: Philip Semanchuk
• Re: Understanding bad estimate (related to FKs?)
  • From: Justin Pryzby
• Understanding bad estimate (related to FKs?)
  • From: Philip Semanchuk
• Profiling tool for postgresql queries
  • From: Debajyoti Datta
• Re: Query Performance / Planner estimate off
  • From: Mats Olsen
• Re: Query Performance / Planner estimate off
  • From: Justin Pryzby
• Re: Query Performance / Planner estimate off
  • From: Mats Olsen
• Re: Query Performance / Planner estimate off
  • From: Justin Pryzby
• Re: Query Performance / Planner estimate off
  • From: Mats Olsen
• Re: CPU Consuming query. Sequential scan despite indexing.
  • From: aditya desai
• Re: CPU Consuming query. Sequential scan despite indexing.
  • From: David G. Johnston
• Re: CPU Consuming query. Sequential scan despite indexing.
  • From: aditya desai
• Re: CPU Consuming query. Sequential scan despite indexing.
  • From: aditya desai
• Re: Query performance
  • From: David G. Johnston
• Re: Query performance
  • From: Justin Pryzby
• Query performance
  • From: Nagaraj Raj
• Re: Query Performance / Planner estimate off
  • From: Sebastian Dressler
• Re: Query Performance / Planner estimate off
  • From: Michael Lewis
• Re: Query Performance / Planner estimate off
  • From: Mats Olsen
• Re: Query Performance / Planner estimate off
  • From: Sebastian Dressler
• Re: Query Performance / Planner estimate off
  • From: Mats Olsen
• Re: Query Performance / Planner estimate off
  • From: Mats Olsen
• Re: Query Performance / Planner estimate off
  • From: Mats Olsen
• Re: Query Performance / Planner estimate off
  • From: Victor Yegorov
• Re: Query Performance / Planner estimate off
  • From: Mats Olsen
• Re: Query Performance / Planner estimate off
  • From: Mats Olsen
• Re: Query Performance / Planner estimate off
  • From: Sushant Pawar
• Re: Query Performance / Planner estimate off
  • From: Victor Yegorov
• Re: Query Performance / Planner estimate off
  • From: Victor Yegorov
• Re: CPU Consuming query. Sequential scan despite indexing.
  • From: aditya desai
• Re: CPU Consuming query. Sequential scan despite indexing.
  • From: aditya desai
• Re: Query Performance / Planner estimate off
  • From: Mats Julian Olsen
• Re: Query Performance / Planner estimate off
  • From: Pavel Stehule
• Re: Query Performance / Planner estimate off
  • From: Mats Julian Olsen
• Re: Query Performance / Planner estimate off
  • From: Pavel Stehule
• Re: Query Performance / Planner estimate off
  • From: Mats Julian Olsen
• Re: Query Performance / Planner estimate off
  • From: David Rowley
• Query Performance / Planner estimate off
  • From: Mats Julian Olsen
• Re: CPU Consuming query. Sequential scan despite indexing.
  • From: aditya desai
• Re: CPU Consuming query. Sequential scan despite indexing.
  • From: Michael Lewis
• Re: CPU Consuming query. Sequential scan despite indexing.
  • From: Laurenz Albe
• Re: CPU Consuming query. Sequential scan despite indexing.
  • From: Michael Lewis
• CPU Consuming query. Sequential scan despite indexing.
  • From: aditya desai
• Re: Poor Performance running Django unit tests after upgrading from 10.6
  • From: Tom Lane
• Re: Slow Query
  • From: Parth Shah
• Re: Poor Performance running Django unit tests after upgrading from 10.6
  • From: Andrew Dunstan
• Re: Poor Performance running Django unit tests after upgrading from 10.6
  • From: Laurenz Albe
• Poor Performance running Django unit tests after upgrading from 10.6
  • From: Roger Hunwicks
• Re: Slow Query
  • From: Michael Lewis
• Re: Slow Query
  • From: Michael Lewis
• Slow Query
  • From: Parth Shah
• Performance issue when we use policies for Row Level Security along with functions
  • From: David G. Johnston
• Re: Performance issue when we use policies for Row Level Security along with functions
  • From: Gopisetty, Ramesh
• Re: Indexing an XMLTABLE query?
  • From: Pavel Stehule
• Indexing an XMLTABLE query?
  • From: Kanninen Anssi EXT
• Re: Too many waits on extension of relation
  • From: avinash varma
• Re: Too many waits on extension of relation
  • From: Laurenz Albe
• Re: Too many waits on extension of relation
  • From: avinash varma
• Re: Too many waits on extension of relation
  • From: MichaelDBA
• Re: Too many waits on extension of relation
  • From: Sushant Pawar
• Re: Too many waits on extension of relation
  • From: Michael Lewis
• Too many waits on extension of relation
  • From: avinash varma
• Re: SSL connection getting rejected on AWS RDS
  • From: Hannah Huang
• Re: SSL connection getting rejected on AWS RDS
  • From: aditya desai
• Re: SSL connection getting rejected on AWS RDS
  • From: Hannah Huang
• SSL connection getting rejected on AWS RDS
  • From: aditya desai
• Re: AWS RDS PostgreSQL CPU Spiking to 100%
  • From: aditya desai
• Re: Is it possible to specify minimum number of rows planner should consider?
  • From: Timothy Garnett
• Re: Is it possible to specify minimum number of rows planner should consider?
  • From: Matthew Bellew
• Re: Is it possible to specify minimum number of rows planner should consider?
  • From: Tom Lane
• Is it possible to specify minimum number of rows planner should consider?
  • From: Timothy Garnett
• Re: AWS RDS PostgreSQL CPU Spiking to 100%
  • From: Prince Pathria
• Re: AWS RDS PostgreSQL CPU Spiking to 100%
  • From: aditya desai
• Re: How to encrypt database password in pgpass or unix file to run batch jobs through shell script
  • From: Bruce Momjian
• How to encrypt database password in pgpass or unix file to run batch jobs through shell script
  • From: aditya desai
• Re: Single column vs composite partial index
  • From: Michael Lewis
• Re: Performance issue when we use policies for Row Level Security along with functions
  • From: Tom Lane
• Re: Performance issue when we use policies for Row Level Security along with functions
  • From: luis . roberto
• Performance issue when we use policies for Row Level Security along with functions
  • From: Gopisetty, Ramesh
• Re: Single column vs composite partial index
  • From: Nagaraj Raj
• Re: Single column vs composite partial index
  • From: Justin Pryzby
• Single column vs composite partial index
  • From: Nagaraj Raj
• Re: autoanalyze creates bad plan, manual analyze fixes it?
  • From: Robert Treat
• Re: autoanalyze creates bad plan, manual analyze fixes it?
  • From: Pavel Stehule
• Re: autoanalyze creates bad plan, manual analyze fixes it?
  • From: Justin Pryzby
• autoanalyze creates bad plan, manual analyze fixes it?
  • From: Robert Treat
• Re: Performance Issue (Not using Index when joining two tables).
  • From: Tom Lane
• Re: Performance Issue (Not using Index when joining two tables).
  • From: Gopisetty, Ramesh
• Re: Performance Issue (Not using Index when joining two tables).
  • From: Michael Lewis
• Re: Performance Issue (Not using Index when joining two tables).
  • From: Tom Lane
• Re: Performance Issue (Not using Index when joining two tables).
  • From: Tomas Vondra
• Performance Issue (Not using Index when joining two tables).
  • From: Gopisetty, Ramesh
• Re: CPU hogged by concurrent SELECT..FOR UPDATE SKIP LOCKED
  • From: Alvaro Herrera
• Re: CPU hogged by concurrent SELECT..FOR UPDATE SKIP LOCKED
  • From: David Rowley
• Re: CPU hogged by concurrent SELECT..FOR UPDATE SKIP LOCKED
  • From: Jim Jarvie
• Re: AWS RDS PostgreSQL CPU Spiking to 100%
  • From: Jeff Janes
• Re: AWS RDS PostgreSQL CPU Spiking to 100%
  • From: Pavel Stehule
• AWS RDS PostgreSQL CPU Spiking to 100%
  • From: aditya desai
• Re: Query Performance in bundled requests
  • From: Justin Pryzby
• Query Performance in bundled requests
  • From: Dirk Krautschick
• AW: Query performance issue
  • From: Dirk Krautschick
• Re: CPU hogged by concurrent SELECT..FOR UPDATE SKIP LOCKED
  • From: Raj
• Re: Query performance issue
  • From: Nagaraj Raj
• Re: Query performance issue
  • From: Michael Lewis
• Re: Query performance issue
  • From: David Rowley
• Re: Query performance issue
  • From: Nagaraj Raj
• Re: Query performance issue
  • From: Michael Lewis
• Re: Query performance issue
  • From: Nagaraj Raj
• Re: Query performance issue
  • From: Michael Lewis
• Re: Query performance issue
  • From: Michael Lewis
• Re: Query performance issue
  • From: Tomas Vondra
• Re: Query performance issue
  • From: Nagaraj Raj
• Re: Query performance issue
  • From: Thomas Kellerer
• Query performance issue
  • From: Nagaraj Raj
• Re: Too few rows expected by Planner on partitioned tables
  • From: Michael Lewis
• Re: Too few rows expected by Planner on partitioned tables
  • From: Julian Wolf
• Re: CPU hogged by concurrent SELECT..FOR UPDATE SKIP LOCKED
  • From: Jeff Janes
• Re: sizing / capacity planning tipps related to expected request or transactions per second
  • From: Pavel Stehule
• Re: sizing / capacity planning tipps related to expected request or transactions per second
  • From: MichaelDBA
• sizing / capacity planning tipps related to expected request or transactions per second
  • From: Dirk Krautschick
• Re: CPU hogged by concurrent SELECT..FOR UPDATE SKIP LOCKED
  • From: Jim Jarvie
• Re: CPU hogged by concurrent SELECT..FOR UPDATE SKIP LOCKED
  • From: Thomas Munro
• Re: CPU hogged by concurrent SELECT..FOR UPDATE SKIP LOCKED
  • From: David Rowley
• Re: CPU hogged by concurrent SELECT..FOR UPDATE SKIP LOCKED
  • From: Michael Lewis
• Re: CPU hogged by concurrent SELECT..FOR UPDATE SKIP LOCKED
  • From: Jim Jarvie
• Re: CPU hogged by concurrent SELECT..FOR UPDATE SKIP LOCKED
  • From: Michael Lewis
• Re: CPU hogged by concurrent SELECT..FOR UPDATE SKIP LOCKED
  • From: Jim Jarvie
• Re: CPU hogged by concurrent SELECT..FOR UPDATE SKIP LOCKED
  • From: Michael Lewis
• Re: CPU hogged by concurrent SELECT..FOR UPDATE SKIP LOCKED
  • From: Jim Jarvie
• Re: Replication lag due to lagging restart_lsn
  • From: Kiran Singh
• Re: Replication lag due to lagging restart_lsn
  • From: Kyotaro Horiguchi
• Re: CPU hogged by concurrent SELECT..FOR UPDATE SKIP LOCKED
  • From: Laurenz Albe
• Re: CPU hogged by concurrent SELECT..FOR UPDATE SKIP LOCKED
  • From: Michael Lewis
• Re: CPU hogged by concurrent SELECT..FOR UPDATE SKIP LOCKED
  • From: Michael Lewis
• Re: CPU hogged by concurrent SELECT..FOR UPDATE SKIP LOCKED
  • From: Henrique Montenegro
• Re: CPU hogged by concurrent SELECT..FOR UPDATE SKIP LOCKED
  • From: Jim Jarvie
• Re: CPU hogged by concurrent SELECT..FOR UPDATE SKIP LOCKED
  • From: Michael Lewis
• CPU hogged by concurrent SELECT..FOR UPDATE SKIP LOCKED
  • From: Jim Jarvie
• Replication lag due to lagging restart_lsn
  • From: Satyam Shekhar
• Re: Query takes way longer with LIMIT, and EXPLAIN takes way longer than actual query
  • From: Justin Pryzby
• Re: Query takes way longer with LIMIT, and EXPLAIN takes way longer than actual query
  • From: Jeff Janes
• Re: Query takes way longer with LIMIT, and EXPLAIN takes way longer than actual query
  • From: Ken Tanzer
• Re: Query takes way longer with LIMIT, and EXPLAIN takes way longer than actual query
  • From: Justin Pryzby
• Query takes way longer with LIMIT, and EXPLAIN takes way longer than actual query
  • From: Ken Tanzer
• Re: Hstore index for full text search
  • From: Tom Lane
• Re: Is there a known bug with SKIP LOCKED and "tuple to be locked was already moved to another partition due to concurrent update"?
  • From: Jim Jarvie
• Re: Hstore index for full text search
  • From: Michael Lewis
• Re: Hstore index for full text search
  • From: Tom Lane
• Re: Hstore index for full text search
  • From: Michael Lewis
• Hstore index for full text search
  • From: Burhan Akbulut
• Problems with Multixacts LWLocks
  • From: Czarek
• Re: Too few rows expected by Planner on partitioned tables
  • From: Julian Wolf
• Re: Too few rows expected by Planner on partitioned tables
  • From: Julian Wolf
• Re: Too few rows expected by Planner on partitioned tables
  • From: Justin Pryzby
• Re: Too few rows expected by Planner on partitioned tables
  • From: Justin Pryzby
• Re: Too few rows expected by Planner on partitioned tables
  • From: Justin Pryzby
• Too few rows expected by Planner on partitioned tables
  • From: Julian Wolf
• Re: Same query taking less time in low configuration machine
  • From: Vishwa Kalyankar
• Re: Same query taking less time in low configuration machine
  • From: Justin Pryzby
• Re: Same query taking less time in low configuration machine
  • From: Vishwa Kalyankar
• Re: Same query taking less time in low configuration machine
  • From: Justin Pryzby
• Same query taking less time in low configuration machine
  • From: Vishwa Kalyankar