Postgres Performance Date Index

• Thread Index

• Re: How to run in parallel in Postgres, EXECUTE_PARALLEL
  • From: Joe Conway
• Re: How to run in parallel in Postgres, EXECUTE_PARALLEL
  • From: Lars Aksel Opsahl
• Re: query that canceled isnt logged
  • From: Tom Lane
• Re: query that canceled isnt logged
  • From: Mariel Cherkassky
• Re: query that canceled isnt logged
  • From: Mariel Cherkassky
• Re: query that canceled isnt logged
  • From: Tom Lane
• query that canceled isnt logged
  • From: Mariel Cherkassky
• Re: Legal disclaimers on emails to this group
  • From: Jean-David Beyer
• Re: How to run in parallel in Postgres
  • From: Lars Aksel Opsahl
• Re: How to run in parallel in Postgres
  • From: Lars Aksel Opsahl
• Re: How to run in parallel in Postgres
  • From: Justin Pryzby
• Re: How to run in parallel in Postgres
  • From: Ondrej Ivanič
• Re: autovacuum locking question
  • From: Jeff Janes
• Re: unexpected result for wastedbytes query after vacuum full
  • From: Justin Pryzby
• Re: Legal disclaimers on emails to this group
  • From: Tim Cross
• threads (Re: Legal disclaimers on emails to this group)
  • From: Justin Pryzby
• Re: Legal disclaimers on emails to this group
  • From: Tom Lane
• Legal disclaimers on emails to this group
  • From: Craig James
• Re: autovacuum locking question
  • From: MichaelDBA
• Re: autovacuum locking question
  • From: Justin Pryzby
• Re: autovacuum locking question
  • From: Jeff Janes
• Re: autovacuum locking question
  • From: Tom Lane
• unexpected result for wastedbytes query after vacuum full
  • From: Mike Schanne
• Re: autovacuum locking question
  • From: Tom Lane
• RE: autovacuum locking question
  • From: Mike Schanne
• RE: autovacuum locking question
  • From: Mike Schanne
• Re: How to run in parallel in Postgres
  • From: Lars Aksel Opsahl
• Re: autovacuum locking question
  • From: Jeff Janes
• Re: autovacuum locking question
  • From: Tom Lane
• RE: autovacuum locking question
  • From: Mike Schanne
• Re: autovacuum locking question
  • From: Michael Lewis
• autovacuum locking question
  • From: Mike Schanne
• Re: Postgres backup tool recommendations for multi-terabyte database in Google Cloud
  • From: Nikolay Samokhvalov
• Re: Postgres backup tool recommendations for multi-terabyte database in Google Cloud
  • From: Craig Jackson
• Re: Postgres backup tool recommendations for multi-terabyte database in Google Cloud
  • From: Craig James
• Postgres backup tool recommendations for multi-terabyte database in Google Cloud
  • From: Craig Jackson
• Re: How to run in parallel in Postgres
  • From: Laurenz Albe
• How to run in parallel in Postgres
  • From: Lars Aksel Opsahl
• Re: performance degredation after upgrade from 9.6 to 12
  • From: Andres Freund
• Re: Make recently inserted/updated records available in the buffer/cache
  • From: Michael Lewis
• Re: Make recently inserted/updated records available in the buffer/cache
  • From: Sachin Divekar
• Re: Make recently inserted/updated records available in the buffer/cache
  • From: MichaelDBA
• Re: Make recently inserted/updated records available in the buffer/cache
  • From: Michael Lewis
• Re: [External] Join queries slow with predicate, limit, and ordering
  • From: Aufar Gilbran
• Re: [External] Join queries slow with predicate, limit, and ordering
  • From: Jeff Janes
• Re: Considerable performance downgrade of v11 and 12 on Windows
  • From: Eugene Podshivalov
• Re: Make recently inserted/updated records available in the buffer/cache
  • From: MichaelDBA
• Re: Make recently inserted/updated records available in the buffer/cache
  • From: Hüseyin Demir
• Make recently inserted/updated records available in the buffer/cache
  • From: Sachin Divekar
• [External] Join queries slow with predicate, limit, and ordering
  • From: Aufar Gilbran
• Re: Considerable performance downgrade of v11 and 12 on Windows
  • From: Laurenz Albe
• Re: Considerable performance downgrade of v11 and 12 on Windows
  • From: Eugene Podshivalov
• Re: Logical replication performance
  • From: Flavio Henrique Araque Gurgel
• Logical replication performance
  • From: Florian Philippon
• Re: Considerable performance downgrade of v11 and 12 on Windows
  • From: Eugene Podshivalov
• Re: Considerable performance downgrade of v11 and 12 on Windows
  • From: Laurenz Albe
• Re: Considerable performance downgrade of v11 and 12 on Windows
  • From: Eugene Podshivalov
• Re: Considerable performance downgrade of v11 and 12 on Windows
  • From: Thomas Kellerer
• Considerable performance downgrade of v11 and 12 on Windows
  • From: Eugene Podshivalov
• Re: performance degredation after upgrade from 9.6 to 12
  • From: Mariel Cherkassky
• Re: performance degredation after upgrade from 9.6 to 12
  • From: Jeff Janes
• Re: performance degredation after upgrade from 9.6 to 12
  • From: John Felix
• Re: performance degredation after upgrade from 9.6 to 12
  • From: Mariel Cherkassky
• Re: performance degredation after upgrade from 9.6 to 12
  • From: Jeff Janes
• Re: performance degredation after upgrade from 9.6 to 12
  • From: Jeff Janes
• Re: performance degredation after upgrade from 9.6 to 12
  • From: Mariel Cherkassky
• Re: performance degredation after upgrade from 9.6 to 12
  • From: Andrew Zakharov
• Re: performance degredation after upgrade from 9.6 to 12
  • From: Thomas Poty
• performance degredation after upgrade from 9.6 to 12
  • From: Mariel Cherkassky
• Re: Postgresql planning time too high
  • From: Tomas Vondra
• Re: Hash Join over Nested Loop
  • From: Pavel Stehule
• Re: Hash Join over Nested Loop
  • From: Luís Roberto Weck
• Re: Re[4]: Postgresql planning time too high
  • From: Michael Lewis
• Re: Hash Join over Nested Loop
  • From: Pavel Stehule
• Re: Hash Join over Nested Loop
  • From: Luís Roberto Weck
• Hash Join over Nested Loop
  • From: Luís Roberto Weck
• Re: Re[4]: Postgresql planning time too high
  • From: Pavel Stehule
• Re[4]: Postgresql planning time too high
  • From: Sterpu Victor
• Re[4]: Postgresql planning time too high
  • From: Sterpu Victor
• Re: Re[2]: Postgresql planning time too high
  • From: Pavel Stehule
• RE: Re[2]: Postgresql planning time too high
  • From: Fırat Güleç
• RE: Postgresql planning time too high
  • From: Fırat Güleç
• Re[3]: Postgresql planning time too high
  • From: Sterpu Victor
• Re[4]: Postgresql planning time too high
  • From: Sterpu Victor
• Re[4]: Postgresql planning time too high
  • From: Sterpu Victor
• Re: Postgresql planning time too high
  • From: Luís Roberto Weck
• Re[2]: Postgresql planning time too high
  • From: Sterpu Victor
• Re[2]: Postgresql planning time too high
  • From: Sterpu Victor
• Postgresql planning time too high
  • From: Sterpu Victor
• Wrong estimations and NL Anti join poor performance
  • From: Andrew Zakharov
• Re: Out of memory error on automatic vacuum
  • From: Tomas Vondra
• Re: Out of memory error on automatic vacuum
  • From: Ekaterina Amez
• Re: Out of memory error on automatic vacuum
  • From: Tomas Vondra
• Re: Out of memory error on automatic vacuum
  • From: Ekaterina Amez
• Re: Out of memory error on automatic vacuum
  • From: Tomas Vondra
• Out of memory error on automatic vacuum
  • From: Ekaterina Amez
• Re: Simple DELETE on modest-size table runs 100% CPU forever
  • From: Craig James
• Re: Simple DELETE on modest-size table runs 100% CPU forever
  • From: Jeff Janes
• Re: Simple DELETE on modest-size table runs 100% CPU forever
  • From: Craig James
• Re: Simple DELETE on modest-size table runs 100% CPU forever
  • From: Jeff Janes
• RE: Simple DELETE on modest-size table runs 100% CPU forever
  • From: Ravi Rai
• Re: Simple DELETE on modest-size table runs 100% CPU forever
  • From: Craig James
• Re: Simple DELETE on modest-size table runs 100% CPU forever
  • From: Andres Freund
• Re: Simple DELETE on modest-size table runs 100% CPU forever
  • From: Justin Pryzby
• Re: Simple DELETE on modest-size table runs 100% CPU forever
  • From: Michael Lewis
• Re: Simple DELETE on modest-size table runs 100% CPU forever
  • From: Alvaro Herrera
• Simple DELETE on modest-size table runs 100% CPU forever
  • From: Craig James
• Re: JSON path
  • From: Jesper Pedersen
• Re: JSON path
  • From: Tom Lane
• JSON path
  • From: Jesper Pedersen
• Re: Parallel Query
  • From: Luís Roberto Weck
• Re: Parallel Query
  • From: Jeff Janes
• Re: Parallel Query
  • From: Jeff Janes
• Re: Parallel Query
  • From: Luís Roberto Weck
• Re: Parallel Query
  • From: Luís Roberto Weck
• Re: Parallel Query
  • From: Tomas Vondra
• Re: Parallel Query
  • From: Jeff Janes
• Parallel Query
  • From: Luís Roberto Weck
• Re: Slow "not in array" operation
  • From: Marco Colli
• Re: Slow "not in array" operation
  • From: Jeff Janes
• Re: Slow "not in array" operation
  • From: Marco Colli
• Re: Slow "not in array" operation
  • From: Jeff Janes
• Re: Slow "not in array" operation
  • From: Rick Otten
• Re: Slow "not in array" operation
  • From: Morris de Oryx
• Re: Slow "not in array" operation
  • From: Marco Colli
• Re: Slow "not in array" operation
  • From: Jeff Janes
• Re: Slow "not in array" operation
  • From: Marco Colli
• Re: Slow "not in array" operation
  • From: Tom Lane
• Re: Slow "not in array" operation
  • From: Michael Lewis
• Re: Slow "not in array" operation
  • From: Marco Colli
• Re: Slow "not in array" operation
  • From: Justin Pryzby
• Re: Slow "not in array" operation
  • From: Michael Lewis
• Re: Slow "not in array" operation
  • From: Marco Colli
• Re: Slow "not in array" operation
  • From: Michael Lewis
• Slow "not in array" operation
  • From: Marco Colli
• Re: FPGA optimization ...
  • From: Tomas Vondra
• Re: Slow planning, fast execution for particular 3-table query
  • From: Justin Pryzby
• Re: Slow planning, fast execution for particular 3-table query
  • From: David Rowley
• Re: Slow planning, fast execution for particular 3-table query
  • From: David Wheeler
• Re: FPGA optimization ...
  • From: Andres Freund
• Re: Slow planning, fast execution for particular 3-table query
  • From: Justin Pryzby
• Re: Slow planning, fast execution for particular 3-table query
  • From: Michael Lewis
• Re: Slow planning, fast execution for particular 3-table query
  • From: David Wheeler
• Re: FPGA optimization ...
  • From: Tomas Vondra
• Re: FPGA optimization ...
  • From: AJG
• Re: FPGA optimization ...
  • From: Gunther
• Re: FPGA optimization ...
  • From: Tomas Vondra
• FPGA optimization ...
  • From: Gunther
• Re: Huge shared hit for small table
  • From: Jeff Janes
• Re: Huge shared hit for small table
  • From: Scott Rankin
• Re: Huge shared hit for small table
  • From: Peter Geoghegan
• Re: Huge shared hit for small table
  • From: Scott Rankin
• Re: Huge shared hit for small table
  • From: Peter Geoghegan
• Re: Huge shared hit for small table
  • From: Jeff Janes
• Re: Huge shared hit for small table
  • From: Scott Rankin
• Re: Huge shared hit for small table
  • From: Andres Freund
• Re: Huge shared hit for small table
  • From: Peter Geoghegan
• Re: Huge shared hit for small table
  • From: Scott Rankin
• Re: Huge shared hit for small table
  • From: Justin Pryzby
• Re: Huge shared hit for small table
  • From: Andres Freund
• Huge shared hit for small table
  • From: Scott Rankin
• Re: Slow planning, fast execution for particular 3-table query
  • From: Pavel Stehule
• Re: Slow planning, fast execution for particular 3-table query
  • From: David Wheeler
• Re: Slow planning, fast execution for particular 3-table query
  • From: Tom Lane
• Re: Slow planning, fast execution for particular 3-table query
  • From: Laurenz Albe
• Re: Slow planning, fast execution for particular 3-table query
  • From: David Wheeler
• Re: Slow planning, fast execution for particular 3-table query
  • From: Laurenz Albe
• Slow planning, fast execution for particular 3-table query
  • From: David Wheeler
• RE: Barman
  • From: Daulat Ram
• Re: Barman
  • From: Tomas Vondra
• Barman
  • From: Daulat Ram
• Re: GIN index on JSONB not used due to lack of nested statistics
  • From: Jeff Janes
• GIN index on JSONB not used due to lack of nested statistics
  • From: Alessandro Baretta
• Re: UNION causes horrible plan on JOIN
  • From: Kyotaro Horiguchi
• Re: UNION causes horrible plan on JOIN
  • From: Craig James
• Re: UNION causes horrible plan on JOIN
  • From: Craig James
• Re: UNION causes horrible plan on JOIN
  • From: Justin Pryzby
• UNION causes horrible plan on JOIN
  • From: Craig James
• Re: Notifications within triggers seem to compromise performance
  • From: Grégoire de Turckheim
• Re: Notifications within triggers seem to compromise performance
  • From: Tom Lane
• Re: Notifications within triggers seem to compromise performance
  • From: Grégoire de Turckheim
• Re: Notifications within triggers seem to compromise performance
  • From: Tom Lane
• Notifications within triggers seem to compromise performance
  • From: Grégoire de Turckheim
• Re: max_connections
  • From: Pavel Stehule
• max_connections
  • From: Joao Junior
• Re: Change in CTE treatment in query plans?
  • From: David Conlin
• Re: Can you please tell us how set this prefetch attribute in following lines.
  • From: Justin Pryzby
• Can you please tell us how set this prefetch attribute in following lines.
  • From: M Tarkeshwar Rao
• Re: pg_stat_bgwriter
  • From: dangal
• Re: pg_stat_bgwriter
  • From: dangal
• Re: Reading explain plans- row estimates/actuals on lower nodes vs next level up
  • From: Tomas Vondra
• Re: pg_stat_bgwriter
  • From: Jeff Janes
• Reading explain plans- row estimates/actuals on lower nodes vs next level up
  • From: Michael Lewis
• Re: Change in CTE treatment in query plans?
  • From: Tom Lane
• Re: pg_stat_bgwriter
  • From: dangal
• Re: pg_stat_bgwriter
  • From: dangal
• Change in CTE treatment in query plans?
  • From: David Conlin
• Re: pg_stat_bgwriter
  • From: Tomas Vondra
• Re: pg_stat_bgwriter
  • From: Justin Pryzby
• Re: Optimising a two column OR check
  • From: Ivan Voras
• Re: pg_stat_bgwriter
  • From: dangal
• Re: pg_stat_bgwriter
  • From: Tomas Vondra
• pg_stat_bgwriter
  • From: dangal
• Re: Optimising a two column OR check
  • From: Ivan Voras
• Re: Optimising a two column OR check
  • From: Andrew Gierth
• Re: Optimising a two column OR check
  • From: MichaelDBA
• Re: Optimising a two column OR check
  • From: Andrew Gierth
• Re: Optimising a two column OR check
  • From: MichaelDBA
• Re: Optimising a two column OR check
  • From: MichaelDBA
• Re: Optimising a two column OR check
  • From: MichaelDBA
• Re: Optimising a two column OR check
  • From: Andrew Gierth
• Re: Optimising a two column OR check
  • From: MichaelDBA
• Re: Optimising a two column OR check
  • From: Jeff Janes
• Re: Optimising a two column OR check
  • From: Andrew Gierth
• Re: Optimising a two column OR check
  • From: Justin Pryzby
• Optimising a two column OR check
  • From: Ivan Voras
• Re: Modification of data in base folder and very large tables
  • From: Jeff Janes
• Re: Modification of data in base folder and very large tables
  • From: Andrew Gierth
• Re: Modification of data in base folder and very large tables
  • From: Ogden Brash
• Re: Modification of data in base folder and very large tables
  • From: Jerry Sievers
• Re: Query slow again after adding an `OR` operation (was: Slow PostgreSQL 10.6 query)
  • From: David Rowley
• Re: Would SSD improve Index Only Scan performance by a lot?
  • From: Jeff Janes
• Re: Query slow again after adding an `OR` operation (was: Slow PostgreSQL 10.6 query)
  • From: Michael Lewis
• Re: Modification of data in base folder and very large tables
  • From: Jeff Janes
• Re: Get the planner used by a query?
  • From: David Rowley
• Re: Query slows when used with view
  • From: Tom Lane
• Re: Query slows when used with view
  • From: Michael Lewis
• Re: Query slows when used with view
  • From: Jeff Janes
• Re: Query slows when used with view
  • From: Michael Lewis
• RE: Query slows when used with view
  • From: Yavuz Selim Sertoğlu (ETIYA)
• Re: Query slows when used with view
  • From: Tom Lane
• Query slows when used with view
  • From: Yavuz Selim Sertoğlu (ETIYA)
• Query slow again after adding an `OR` operation (was: Slow PostgreSQL 10.6 query)
  • From: Behrang Saeedzadeh
• Re: Modification of data in base folder and very large tables
  • From: Andrew Gierth
• Modification of data in base folder and very large tables
  • From: Ogden Brash
• Get the planner used by a query?
  • From: Behrang Saeedzadeh
• Re: Would SSD improve Index Only Scan performance by a lot?
  • From: Matthew Hall
• Re: Would SSD improve Index Only Scan performance by a lot?
  • From: Rick Otten
• Sv: Would SSD improve Index Only Scan performance by a lot?
  • From: Andreas Joseph Krogh
• Would SSD improve Index Only Scan performance by a lot?
  • From: Arya F
• Re: Out of Memory errors are frustrating as heck!
  • From: Merlin Moncure
• Re: Out of Memory errors are frustrating as heck!
  • From: Merlin Moncure
• Re: distinct on extract returns composite type
  • From: Michael Lewis
• Re: Slow PostgreSQL 10.6 query
  • From: Behrang Saeedzadeh
• Re: Out of Memory errors are frustrating as heck!
  • From: Tomas Vondra
• Re: Out of Memory errors are frustrating as heck!
  • From: Tomas Vondra
• Re: Delete huge Table under XFS
  • From: Tomas Vondra
• Re: Slow PostgreSQL 10.6 query
  • From: Tomas Vondra
• Re: Query went slow all of sudden. ON V 11.3
  • From: Tomas Vondra
• Re: Query went slow all of sudden. ON V 11.3
  • From: Michael Lewis
• Re: Query went slow all of sudden. ON V 11.3
  • From: nikhil raj
• Re: Query went slow all of sudden. ON V 11.3
  • From: Justin Pryzby
• Query went slow all of sudden. ON V 11.3
  • From: nikhil raj
• Re: Some observations on very slow pg_restore operations
  • From: Justin Pryzby
• Re: Some observations on very slow pg_restore operations
  • From: Ogden Brash
• Re: Some observations on very slow pg_restore operations
  • From: MichaelDBA
• Some observations on very slow pg_restore operations
  • From: Ogden Brash
• Re: pg12 - partition by column that might have null values
  • From: Michael Lewis
• Re: pg12 - partition by column that might have null values
  • From: Mariel Cherkassky
• RE: pg12 - partition by column that might have null values
  • From: Mike Sofen
• Re: pg12 - partition by column that might have null values
  • From: Mariel Cherkassky
• RE: pg12 - partition by column that might have null values
  • From: Mike Sofen
• Re: pg12 - partition by column that might have null values
  • From: Mariel Cherkassky
• Re: pg12 - partition by column that might have null values
  • From: Laurenz Albe
• pg12 - partition by column that might have null values
  • From: Mariel Cherkassky
• Re: Slow PostgreSQL 10.6 query
  • From: Behrang Saeedzadeh
• Re: Slow PostgreSQL 10.6 query
  • From: Tom Lane
• Slow PostgreSQL 10.6 query
  • From: Behrang Saeedzadeh
• Re: distinct on extract returns composite type
  • From: Mariel Cherkassky
• Re: distinct on extract returns composite type
  • From: Tom Lane
• Re: distinct on extract returns composite type
  • From: Mariel Cherkassky
• Re: sequence depends on many tables
  • From: Tom Lane
• Re: distinct on extract returns composite type
  • From: Félix GERZAGUET
• distinct on extract returns composite type
  • From: Mariel Cherkassky
• Re: sequence depends on many tables
  • From: Mariel Cherkassky
• Re: Slow pg_publication_tables with many schemas and tables
  • From: Edilmar Alves
• Re: Analyze on slave promoted.
  • From: Vik Fearing
• Re: Autovacuum is cleaning very less dead tuples
  • From: Laurenz Albe
• Autovacuum is cleaning very less dead tuples
  • From: Amarendra Konda
• RE: Monitor Postgres database status on Docker
  • From: Daulat Ram
• Re: Slow pg_publication_tables with many schemas and tables
  • From: Tom Lane
• Slow pg_publication_tables with many schemas and tables
  • From: Edilmar Alves
• Re: Analyze on slave promoted.
  • From: Pavel Stehule
• Analyze on slave promoted.
  • From: Joao Junior
• Re: sequence depends on many tables
  • From: Laurenz Albe
• Re: sequence depends on many tables
  • From: Mariel Cherkassky
• Re: sequence depends on many tables
  • From: Laurenz Albe
• sequence depends on many tables
  • From: Mariel Cherkassky
• Re: Slow query on V12.
  • From: Luís Roberto Weck
• Re: Slow query on V12.
  • From: Tom Lane
• Re: Slow query on V12.
  • From: Luís Roberto Weck
• Re: Slow query on V12.
  • From: Luís Roberto Weck
• Re: Slow query on V12.
  • From: nikhil raj
• Slow query on V12.
  • From: Luís Roberto Weck
• Re: pg12 partitions question
  • From: Mariel Cherkassky
• pg12 partitions question
  • From: Mariel Cherkassky
• Re: Slow query on a one-tuple table
  • From: MichaelDBA
• Re: Slow query on a one-tuple table
  • From: Tom Lane
• Re: Slow query on a one-tuple table
  • From: Luís Roberto Weck
• Re: Slow query on a one-tuple table
  • From: Michael Lewis
• Re: Slow query on a one-tuple table
  • From: Luís Roberto Weck
• Re: Surprising benchmark count(1) vs. count(*)
  • From: Tom Lane
• Re: Surprising benchmark count(1) vs. count(*)
  • From: Adam Brusselback
• Re: Slow query on a one-tuple table
  • From: Luís Roberto Weck
• Re: Slow query on a one-tuple table
  • From: Luís Roberto Weck
• RE: Slow query on a one-tuple table
  • From: Igor Neyman
• Re: Slow query on a one-tuple table
  • From: Luís Roberto Weck
• RE: Slow query on a one-tuple table
  • From: Igor Neyman
• Re: Slow query on a one-tuple table
  • From: Luís Roberto Weck
• Re: Delete huge Table under XFS
  • From: Christoph Berg
• Re: Slow query on a one-tuple table
  • From: Michael Lewis
• Re: Delete huge Table under XFS
  • From: Joao Junior
• Slow query on a one-tuple table
  • From: Luís Roberto Weck
• Re: Delete huge Table under XFS
  • From: Andreas Kretschmer
• Re: comparing output of internal pg tables of referenced tables
  • From: Tom Lane
• Delete huge Table under XFS
  • From: Joao Junior
• comparing output of internal pg tables of referenced tables
  • From: Mariel Cherkassky
• Re: Surprising benchmark count(1) vs. count(*)
  • From: Tom Lane
• Re: Surprising benchmark count(1) vs. count(*)
  • From: Thomas Kellerer
• Re: Surprising benchmark count(1) vs. count(*)
  • From: Laurenz Albe
• Surprising benchmark count(1) vs. count(*)
  • From: Thomas Kellerer
• Re: pg12 - migrate tables to partitions structure
  • From: Michael Lewis
• Re: Question regarding fast-hashing in PGSQL
  • From: Tom Lane
• Re: pg12 - migrate tables to partitions structure
  • From: Mariel Cherkassky
• Re: pg12 - migrate tables to partitions structure
  • From: Michael Lewis
• Re: pg12 - migrate tables to partitions structure
  • From: Mariel Cherkassky
• Re: pg12 - migrate tables to partitions structure
  • From: Michael Lewis
• pg12 - migrate tables to partitions structure
  • From: Mariel Cherkassky
• Re: Question regarding fast-hashing in PGSQL
  • From: Stephen Conley
• Re: Question regarding fast-hashing in PGSQL
  • From: Adam Brusselback
• Question regarding fast-hashing in PGSQL
  • From: Stephen Conley
• Re: does max_connections affect the query planner
  • From: Jeff Janes
• Re: does max_connections affect the query planner
  • From: Bob Jolliffe
• Re: does max_connections affect the query planner
  • From: Tom Lane
• does max_connections affect the query planner
  • From: Bob Jolliffe
• Re: Query execution time Vs Cost
  • From: Amarendra Konda
• Re: Query execution time Vs Cost
  • From: Justin Pryzby
• Query execution time Vs Cost
  • From: Amarendra Konda
• Re: select distinct runs slow on pg 10.6
  • From: Dinesh Somani
• Re: select distinct runs slow on pg 10.6
  • From: Merlin Moncure
• Re: select distinct runs slow on pg 10.6
  • From: Rick Otten
• Re: select distinct runs slow on pg 10.6
  • From: Dinesh Somani
• Re: select distinct runs slow on pg 10.6
  • From: Merlin Moncure
• Re: select distinct runs slow on pg 10.6
  • From: Rick Otten
• Re: select distinct runs slow on pg 10.6
  • From: yash mehta
• Re: select distinct runs slow on pg 10.6
  • From: Michael Lewis
• Re: select distinct runs slow on pg 10.6
  • From: Flo Rance
• Re: select distinct runs slow on pg 10.6
  • From: Justin Pryzby
• Re: select distinct runs slow on pg 10.6
  • From: yash mehta
• Re: select distinct runs slow on pg 10.6
  • From: Flo Rance
• select distinct runs slow on pg 10.6
  • From: yash mehta
• Re: select distinct runs slow on pg 10.6
  • From: yash mehta
• Re: Incorrect choice of Nested Loop for a skewed distribution
  • From: Oleg Kharin
• Re: Incorrect choice of Nested Loop for a skewed distribution
  • From: Justin Pryzby
• Re: Upsert performance considerations (~1 mil/hour)
  • From: Jeff Janes
• Re: Upsert performance considerations (~1 mil/hour)
  • From: Fredrik Blomqvist
• Upsert performance considerations (~1 mil/hour)
  • From: Fredrik Blomqvist
• Incorrect choice of Nested Loop for a skewed distribution
  • From: Oleg Kharin
• Re: UPGRADE TO PG11 CAUSED DEGREDATION IN PERFORMANCE
  • From: Merlin Moncure
• Re: Erratically behaving query needs optimization
  • From: Barbu Paul - Gheorghe
• Re: Erratically behaving query needs optimization
  • From: Jeff Janes
• Re: Erratically behaving query needs optimization
  • From: Justin Pryzby
• Re: Erratically behaving query needs optimization
  • From: Barbu Paul - Gheorghe
• Re: Erratically behaving query needs optimization
  • From: Jeff Janes
• Re: Extremely slow HashAggregate in simple UNION query
  • From: Andres Freund
• Re: Extremely slow HashAggregate in simple UNION query
  • From: Tom Lane
• Re: Extremely slow HashAggregate in simple UNION query
  • From: Jeff Janes
• Re: Out of Memory errors are frustrating as heck!
  • From: Gunther
• pg_basebackup is taking an unusually long time with Postgres 11.3
  • From: andy andy
• Re: Out of Memory errors are frustrating as heck!
  • From: Gunther
• Re: Out of Memory errors are frustrating as heck!
  • From: Gunther
• Re: Out of Memory errors are frustrating as heck!
  • From: Tom Lane
• Re: Extremely slow count (simple query, with index)
  • From: Justin Pryzby
• Re: Extremely slow count (simple query, with index)
  • From: Marco Colli
• Re: Erratically behaving query needs optimization
  • From: legrand legrand
• Re: Extremely slow count (simple query, with index)
  • From: Michael Lewis
• Re: Extremely slow count (simple query, with index)
  • From: Justin Pryzby
• Re: Erratically behaving query needs optimization
  • From: Barbu Paul - Gheorghe
• Re: Erratically behaving query needs optimization
  • From: Barbu Paul - Gheorghe
• Re: Erratically behaving query needs optimization
  • From: Barbu Paul - Gheorghe
• Re: Extremely slow count (simple query, with index)
  • From: Ravikumar Reddy
• Re: Extremely slow count (simple query, with index)
  • From: MichaelDBA
• Extremely slow count (simple query, with index)
  • From: Marco Colli
• Re: Erratically behaving query needs optimization
  • From: Luís Roberto Weck
• Re: Extremely slow HashAggregate in simple UNION query
  • From: Felix Geisendörfer
• Re: Extremely slow HashAggregate in simple UNION query
  • From: Pavel Stehule
• Re: Extremely slow HashAggregate in simple UNION query
  • From: Jeff Janes
• Re: Erratically behaving query needs optimization
  • From: Luís Roberto Weck
• Re: Erratically behaving query needs optimization
  • From: Barbu Paul - Gheorghe
• Re: Extremely slow HashAggregate in simple UNION query
  • From: Michael Lewis
• Re: Extremely slow HashAggregate in simple UNION query
  • From: Andres Freund
• Re: Extremely slow HashAggregate in simple UNION query
  • From: Felix Geisendörfer
• Re: Extremely slow HashAggregate in simple UNION query
  • From: Andres Freund
• Re: Extremely slow HashAggregate in simple UNION query
  • From: Pavel Stehule
• Extremely slow HashAggregate in simple UNION query
  • From: Felix Geisendörfer
• Re: Erratically behaving query needs optimization
  • From: MichaelDBA
• Re: Erratically behaving query needs optimization
  • From: Luís Roberto Weck
• Erratically behaving query needs optimization
  • From: Barbu Paul - Gheorghe
• pg11 list partitions vs hash partitions
  • From: Mariel Cherkassky
• Re: UPGRADE TO PG11 CAUSED DEGREDATION IN PERFORMANCE
  • From: Pavel Stehule
• UPGRADE TO PG11 CAUSED DEGREDATION IN PERFORMANCE
  • From: Mariel Cherkassky
• Re: [UNVERIFIED SENDER] Re: Continuous Performance Test
  • From: Jean Baro
• Re: [UNVERIFIED SENDER] Re: Continuous Performance Test
  • From: Nasby, Jim
• Re: Continuous Performance Test
  • From: Nasby, Jim
• Continuous Performance Test
  • From: Jean Baro
• Continuous Performance Test
  • From: Jean Baro
• Re: Re: performance bottlenecks on lock transactionid
  • From: Laurenz Albe
• RE: ORA-24345: A Truncation or null fetch error occurred -ora2pg
  • From: Daulat Ram
• re:Re: performance bottlenecks on lock transactionid
  • From: 王若楠
• Re: performance bottlenecks on lock transactionid
  • From: Laurenz Albe
• Re: ORA-24345: A Truncation or null fetch error occurred -ora2pg
  • From: Adrian Klaver
• RE: ORA-24345: A Truncation or null fetch error occurred -ora2pg
  • From: Daulat Ram
• Re: ORA-24345: A Truncation or null fetch error occurred -ora2pg
  • From: Luca Ferrari
• performance bottlenecks on lock transactionid
  • From: =?gb18030?b?zfXI9Omq?=
• Re: Last event per user
  • From: Luís Roberto Weck
• Re: zabbix on postgresql - very slow delete of events
  • From: Kristian Ejvind
• ORA-24345: A Truncation or null fetch error occurred -ora2pg
  • From: Daulat Ram
• Re: Strange runtime partition pruning behaviour with 11.4
  • From: Sverre Boschman
• ODP: Planner performance in partitions
  • From: Piotr Włodarczyk
• Re: Last event per user
  • From: Michael Lewis
• Re: Last event per user
  • From: Luís Roberto Weck
• Re:
  • From: Michael Lewis
• Re:
  • From: Luís Roberto Weck
• Re: Planner performance in partitions
  • From: Michael Lewis
• Re: Last event per user
  • From: Michael Lewis
• Re: Last event per user
  • From: Luís Roberto Weck
• Re: Planner performance in partitions
  • From: David Rowley
• Re: Last event per user
  • From: Michael Lewis
• Last event per user
  • From: Luís Roberto Weck
• Re: Planner performance in partitions
  • From: Michael Lewis
• ODP: Planner performance in partitions
  • From: Piotr Włodarczyk
• Re: Planner performance in partitions
  • From: MichaelDBA
• Re: Planner performance in partitions
  • From: Michael Lewis
• Planner performance in partitions
  • From: Piotr Włodarczyk
• Re: Bitmap heap scan performance
  • From: Jeremy Finzel
• Re: Bitmap heap scan performance
  • From: Rob Emery
• Re: Postgres not using correct indices for views.
  • From: Tom Lane
• Re: Postgres not using correct indices for views.
  • From: Michaeldba@xxxxxxxxxxx
• Re: Postgres not using correct indices for views.
  • From: Thomas Rosenstein
• Re: Postgres not using correct indices for views.
  • From: Tom Lane
• Re: Bitmap heap scan performance
  • From: Jeff Janes
• Bitmap heap scan performance
  • From: Rob Emery
• Re: Postgres not using correct indices for views.
  • From: Tom Lane
• Re: Postgres not using correct indices for views.
  • From: Thomas Rosenstein
• Re: Postgres not using correct indices for views.
  • From: Thomas Rosenstein
• Re: Postgres not using correct indices for views.
  • From: Tom Lane
• Postgres not using correct indices for views.
  • From: Thomas Rosenstein
• Re: improving windows functions performance
  • From: Andreas Kretschmer
• improving windows functions performance
  • From: Mariel Cherkassky
• Re: Strange runtime partition pruning behaviour with 11.4
  • From: Thomas Kellerer
• Re: Strange runtime partition pruning behaviour with 11.4
  • From: MichaelDBA
• Re: Strange runtime partition pruning behaviour with 11.4
  • From: Tom Lane
• Re: Strange runtime partition pruning behaviour with 11.4
  • From: Andreas Kretschmer
• Re: Strange runtime partition pruning behaviour with 11.4
  • From: Thomas Kellerer
• Re: Strange runtime partition pruning behaviour with 11.4
  • From: Andreas Kretschmer
• Re: Strange runtime partition pruning behaviour with 11.4
  • From: MichaelDBA
• Strange runtime partition pruning behaviour with 11.4
  • From: Thomas Kellerer
• Re: PSQL performance - TPS
  • From: Imre Samu
• Re: PSQL performance - TPS
  • From: Shital A
• Re: PSQL performance - TPS
  • From: Rick Otten
• Re: PSQL performance - TPS
  • From: Andres Freund
• Re: PSQL performance - TPS
  • From: Purav Chovatia
• Re: PSQL performance - TPS
  • From: Andres Freund
• Re: PSQL performance - TPS
  • From: Shital A
• Re: PSQL performance - TPS
  • From: Gavin Flower
• PSQL performance - TPS
  • From: Shital A
• Re: Oracle to postgres migration via ora2pg (blob data)
  • From: Gilles Darold
• Re: Oracle to postgres migration via ora2pg (blob data)
  • From: Amol Tarte
• SV: Oracle to postgres migration via ora2pg (blob data)
  • From: Niels Jespersen
• Oracle to postgres migration via ora2pg (blob data)
  • From: Daulat Ram
• Re: A question regarding streaming replication
  • From: Holger Jakobs
• A question regarding streaming replication
  • From: Mariel Cherkassky
• Re: High concurrency same row (inventory)
  • From: Jean Baro
• Re: High concurrency same row (inventory)
  • From: MichaelDBA
• Re: High concurrency same row (inventory)
  • From: Jean Baro
• Re: High concurrency same row (inventory)
  • From: Jean Baro
• Re: High concurrency same row (inventory)
  • From: Jean Baro
• Re: High concurrency same row (inventory)
  • From: Michael Lewis
• Partial join
  • From: Arne Roland
• Re: High concurrency same row (inventory)
  • From: Jean Baro
• Re: High concurrency same row (inventory)
  • From: MichaelDBA
• Re: High concurrency same row (inventory)
  • From: Jayadevan M
• Re: High concurrency same row (inventory)
  • From: Rick Otten
• Re: Standard uuid vs. custom data type uuid_v1
  • From: Ancoron Luciferis
• High concurrency same row (inventory)
  • From: Jean Baro
• Re: Standard uuid vs. custom data type uuid_v1
  • From: Tomas Vondra
• Standard uuid vs. custom data type uuid_v1
  • From: Ancoron Luciferis
• Re: zabbix on postgresql - very slow delete of events
  • From: Maxim Boguk
• Re: zabbix on postgresql - very slow delete of events
  • From: Kristian Ejvind
• Re: zabbix on postgresql - very slow delete of events
  • From: Maxim Boguk
• Re: zabbix on postgresql - very slow delete of events
  • From: Maxim Boguk
• Re: zabbix on postgresql - very slow delete of events
  • From: Kristian Ejvind
• Re: zabbix on postgresql - very slow delete of events
  • From: Kenneth Marshall
• Re: zabbix on postgresql - very slow delete of events
  • From: Kristian Ejvind
• Re: zabbix on postgresql - very slow delete of events
  • From: Kenneth Marshall
• zabbix on postgresql - very slow delete of events
  • From: Kristian Ejvind
• Re: Speeding up query pulling comments from pg_catalog
  • From: Tom Lane
• Re: benchmarking effective_io_concurrency
  • From: Merlin Moncure
• Re: Speeding up query pulling comments from pg_catalog
  • From: Ken Tanzer
• Re: benchmarking effective_io_concurrency
  • From: Fabio Pardi
• Re: benchmarking effective_io_concurrency
  • From: Rick Otten
• benchmarking effective_io_concurrency
  • From: Fabio Pardi
• Re: Speeding up query pulling comments from pg_catalog
  • From: Tom Lane
• Re: Speeding up query pulling comments from pg_catalog
  • From: Ken Tanzer
• Re: Speeding up query pulling comments from pg_catalog
  • From: Tom Lane
• Speeding up query pulling comments from pg_catalog
  • From: Ken Tanzer
• Re: Searching in varchar column having 100M records
  • From: mgbii bax
• Re: Searching in varchar column having 100M records
  • From: Tomas Vondra
• Re: Searching in varchar column having 100M records
  • From: Michael Lewis
• Re: Searching in varchar column having 100M records
  • From: mayank rupareliya
• Re: Perplexing, regular decline in performance
  • From: Andres Freund
• Re: Searching in varchar column having 100M records
  • From: Gavin Flower
• Re: Perplexing, regular decline in performance
  • From: Hugh Ranalli
• Re: Searching in varchar column having 100M records
  • From: Tomas Vondra
• Re: Searching in varchar column having 100M records
  • From: mayank rupareliya
• Re: Searching in varchar column having 100M records
  • From: Gavin Flower
• Re: Perplexing, regular decline in performance
  • From: Andres Freund
• Re: Perplexing, regular decline in performance
  • From: Alvaro Herrera
• Re: Perplexing, regular decline in performance
  • From: Hugh Ranalli
• Re: Searching in varchar column having 100M records
  • From: David G. Johnston
• Re: Searching in varchar column having 100M records
  • From: Andreas Kretschmer
• Re: Searching in varchar column having 100M records
  • From: Tomas Vondra
• Re: Searching in varchar column having 100M records
  • From: Sergei Kornilov
• Searching in varchar column having 100M records
  • From: mayank rupareliya
• Re: Filtering on an enum field in a foreign table
  • From: Vladimir Ryabtsev
• Re: Filtering on an enum field in a foreign table
  • From: Vladimir Ryabtsev
• Re: Filtering on an enum field in a foreign table
  • From: Nikolay Samokhvalov
• Filtering on an enum field in a foreign table
  • From: Vladimir Ryabtsev
• Re: Optimizing `WHERE x IN` query
  • From: Michael Lewis
• Re: Optimizing `WHERE x IN` query
  • From: Omar Roth
• Re: Custom opclass for column statistics?
  • From: Ancoron Luciferis
• Re: UUID v1 optimizations...
  • From: Ancoron Luciferis
• Re: Optimizing `WHERE x IN` query
  • From: Nicolas Charles
• Re: Optimizing `WHERE x IN` query
  • From: Omar Roth
• Re: UUID v1 optimizations...
  • From: Peter Geoghegan
• Re: Custom opclass for column statistics?
  • From: Tom Lane
• Re: Optimizing `WHERE x IN` query
  • From: Thomas Kellerer
• Optimizing `WHERE x IN` query
  • From: Omar Roth
• Re: Custom opclass for column statistics?
  • From: Ancoron Luciferis
• Re: Custom opclass for column statistics?
  • From: Tomas Vondra
• Re: Custom opclass for column statistics?
  • From: Ancoron Luciferis
• Re: Custom opclass for column statistics?
  • From: Tomas Vondra
• Custom opclass for column statistics?
  • From: Ancoron Luciferis
• Re: Perplexing, regular decline in performance
  • From: Justin Pryzby
• Re: scans on table fail to be excluded by partition bounds
  • From: David Rowley
• Re: Perplexing, regular decline in performance
  • From: Tom Lane
• Re: Perplexing, regular decline in performance
  • From: Alvaro Herrera
• Re: Perplexing, regular decline in performance
  • From: Peter Geoghegan
• Re: Perplexing, regular decline in performance
  • From: Hugh Ranalli
• Re: Perplexing, regular decline in performance
  • From: Hugh Ranalli
• Re: Perplexing, regular decline in performance
  • From: Peter Geoghegan
• Re: Perplexing, regular decline in performance
  • From: Hugh Ranalli
• Re: scans on table fail to be excluded by partition bounds
  • From: Justin Pryzby
• RE: Max_connections limit
  • From: Igor Neyman
• Re: Incorrect index used in few cases..
  • From: AminPG Jaffer
• Re: Max_connections limit
  • From: Rick Otten
• Re: Max_connections limit
  • From: Hervé Schweitzer (HER)
• Re: Max_connections limit
  • From: Laurenz Albe
• Max_connections limit
  • From: Daulat Ram
• Re: Perplexing, regular decline in performance
  • From: Justin Pryzby
• Re: Perplexing, regular decline in performance
  • From: Benjamin Scherrey
• Re: Perplexing, regular decline in performance
  • From: Justin Pryzby
• Re: Perplexing, regular decline in performance
  • From: Benjamin Scherrey
• Perplexing, regular decline in performance
  • From: Hugh Ranalli
• Re: materialized view refresh of a foreign table
  • From: Rick Otten
• RE: scans on table fail to be excluded by partition bounds
  • From: Steven Winfield
• scans on table fail to be excluded by partition bounds
  • From: Justin Pryzby
• Re: Incorrect index used in few cases..
  • From: AminPG Jaffer
• monitoring tuple_count vs dead_tuple_count
  • From: Mariel Cherkassky
• materialized view refresh of a foreign table
  • From: Rick Otten
• Using indexes in RLS policies (sub)queries
  • From: Grégory EL MAJJOUTI
• RE: EXPLAIN ANALYZE of BRIN bitmap index scan with disjunction
  • From: Chris Wilson
• RE: EXPLAIN ANALYZE of BRIN bitmap index scan with disjunction
  • From: Chris Wilson
• Re: EXPLAIN ANALYZE of BRIN bitmap index scan with disjunction
  • From: Simon Riggs
• Re: EXPLAIN ANALYZE of BRIN bitmap index scan with disjunction
  • From: Michael Lewis
• Re: EXPLAIN ANALYZE of BRIN bitmap index scan with disjunction
  • From: Justin Pryzby
• Re: EXPLAIN ANALYZE of BRIN bitmap index scan with disjunction
  • From: Michael Lewis
• Re: EXPLAIN ANALYZE of BRIN bitmap index scan with disjunction
  • From: Simon Riggs
• Re: EXPLAIN ANALYZE of BRIN bitmap index scan with disjunction
  • From: Justin Pryzby
• Re: EXPLAIN ANALYZE of BRIN bitmap index scan with disjunction
  • From: Simon Riggs
• RE: EXPLAIN ANALYZE of BRIN bitmap index scan with disjunction
  • From: Chris Wilson
• Re: EXPLAIN ANALYZE of BRIN bitmap index scan with disjunction
  • From: Simon Riggs
• EXPLAIN ANALYZE of BRIN bitmap index scan with disjunction
  • From: Chris Wilson
• Re: Incorrect index used in few cases..
  • From: Tom Lane
• Re: Incorrect index used in few cases..
  • From: Andres Freund
• Re: Incorrect index used in few cases..
  • From: Peter Geoghegan
• Re: Incorrect index used in few cases..
  • From: Tom Lane
• Re: Incorrect index used in few cases..
  • From: AminPG Jaffer
• Re: Incorrect index used in few cases..
  • From: Tom Lane
• Incorrect index used in few cases..
  • From: AminPG Jaffer
• Re: wal_log_hints benchmarks
  • From: Fabio Pardi
• Re: wal_log_hints benchmarks
  • From: Michael Paquier
• Re: Fwd: upgrade to PG11 on secondary fails (no initdb was launched)
  • From: Stephen Frost
• Re: Fwd: upgrade to PG11 on secondary fails (no initdb was launched)
  • From: Stephen Frost
• Re: Fwd: upgrade to PG11 on secondary fails (no initdb was launched)
  • From: Bruce Momjian
• Re: Fwd: upgrade to PG11 on secondary fails (no initdb was launched)
  • From: Bruce Momjian
• wal_log_hints benchmarks
  • From: Fabio Pardi
• Re: Fwd: upgrade to PG11 on secondary fails (no initdb was launched)
  • From: Fabio Pardi
• Re: Fwd: upgrade to PG11 on secondary fails (no initdb was launched)
  • From: Bruce Momjian
• Re: UUID v1 optimizations...
  • From: Ancoron Luciferis
• Re: Strange query behaviour between 9.4 and 12beta1
  • From: Tomas Vondra
• Re: Shortest offline window on database migration
  • From: Stephen Frost
• Strange query behaviour between 9.4 and 12beta1
  • From: Vasilis Ventirozos
• Re: Shortest offline window on database migration
  • From: Haroldo Kerry
• Re: Sv: JIT in PostgreSQL 12 ?
  • From: Justin Pryzby
• Re: improve wals replay on secondary
  • From: Fabio Pardi
• Re: Shortest offline window on database migration
  • From: Fabio Pardi
• Re: Shortest offline window on database migration
  • From: Ian Lawrence Barwick
• Re: Shortest offline window on database migration
  • From: Jeff Janes
• Re: Shortest offline window on database migration
  • From: Haroldo Kerry
• Re: Shortest offline window on database migration
  • From: Haroldo Kerry
• RE: Shortest offline window on database migration
  • From: Steven Winfield
• Re: Shortest offline window on database migration
  • From: Tomas Vondra
• Shortest offline window on database migration
  • From: Haroldo Kerry
• Re: improve wals replay on secondary
  • From: Mariel Cherkassky
• Re: improve wals replay on secondary
  • From: Nikolay Samokhvalov
• Re: JIT in PostgreSQL 12 ?
  • From: Andreas Karlsson
• Re: Sv: JIT in PostgreSQL 12 ?
  • From: Andreas Joseph Krogh
• Re: Sv: JIT in PostgreSQL 12 ?
  • From: Tobias Gierke
• Sv: JIT in PostgreSQL 12 ?
  • From: Andreas Joseph Krogh
• Re: improve wals replay on secondary
  • From: Mariel Cherkassky
• Re: improve wals replay on secondary
  • From: Fabio Pardi
• JIT in PostgreSQL 12 ?
  • From: Tobias Gierke
• Re: improve wals replay on secondary
  • From: Mariel Cherkassky
• Re: improve wals replay on secondary
  • From: Fabio Pardi
• Re: improve wals replay on secondary
  • From: Fabio Pardi
• Re: improve wals replay on secondary
  • From: Mariel Cherkassky
• Re: improve wals replay on secondary
  • From: Fabio Pardi
• Re: improve wals replay on secondary
  • From: Fabio Pardi
• improve wals replay on secondary
  • From: Mariel Cherkassky
• Re: UUID v1 optimizations...
  • From: Morris de Oryx
• Re: UUID v1 optimizations...
  • From: Morris de Oryx
• Re: UUID v1 optimizations...
  • From: Tomas Vondra
• Re: UUID v1 optimizations...
  • From: Morris de Oryx
• Re: UUID v1 optimizations...
  • From: Ancoron Luciferis
• Re: UUID v1 optimizations...
  • From: Ancoron Luciferis
• Re: UUID v1 optimizations...
  • From: Morris de Oryx
• Re: UUID v1 optimizations...
  • From: Tomas Vondra
• Re: UUID v1 optimizations...
  • From: Ancoron Luciferis
• Re: UUID v1 optimizations...
  • From: Tomas Vondra
• Re: UUID v1 optimizations...
  • From: Ancoron Luciferis
• Re: UUID v1 optimizations...
  • From: Tom Lane
• Re: UUID v1 optimizations...
  • From: Tomas Vondra
• Re: UUID v1 optimizations...
  • From: Tom Lane
• Re: UUID v1 optimizations...
  • From: Ancoron Luciferis
• Re: UUID v1 optimizations...
  • From: Ancoron Luciferis
• Re: UUID v1 optimizations...
  • From: Vitalii Tymchyshyn
• Re: UUID v1 optimizations...
  • From: Ancoron Luciferis
• Re: UUID v1 optimizations...
  • From: Ancoron Luciferis
• Re: UUID v1 optimizations...
  • From: Tom Lane
• Re: UUID v1 optimizations...
  • From: Peter Eisentraut
• UUID v1 optimizations...
  • From: Ancoron Luciferis
• Re: Use Postgres as a column store by creating one table per column
  • From: Mark Kirkwood
• Re: Use Postgres as a column store by creating one table per column
  • From: Stephen Frost
• Re: Use Postgres as a column store by creating one table per column
  • From: Tomas Vondra
• Re: Generic Plans for Prepared Statement are 158155 times slower than Custom Plans
  • From: Tom Lane
• Re: Fwd: upgrade to PG11 on secondary fails (no initdb was launched)
  • From: Stephen Frost
• Re: Fwd: upgrade to PG11 on secondary fails (no initdb was launched)
  • From: Fabio Pardi
• RE: upgrade to PG11 on secondary fails (no initdb was launched)
  • From: Greg Clough
• Fwd: upgrade to PG11 on secondary fails (no initdb was launched)
  • From: Mariel Cherkassky
• RE: Re: Generic Plans for Prepared Statement are 158155 times slower than Custom Plans
  • From: Naik, Sameer
• Re: Analyze results in more expensive query plan
  • From: Jeremy Altavilla
• Re: Use Postgres as a column store by creating one table per column
  • From: George Neuner
• Re: pg_restore takes more time on creation of rules
  • From: Tomas Vondra
• Re: pg_restore takes more time on creation of rules
  • From: Mariel Cherkassky
• Re: pg_restore takes more time on creation of rules
  • From: Tomas Vondra