Postgres Performance Date Index

• Thread Index

• Re: Possible to find disk IOs for a Query?
  • From: Mark Kirkwood
• Re: Possible to find disk IOs for a Query?
  • From: Lukas Fittl
• Re: Possible to find disk IOs for a Query?
  • From: Ben Chobot
• Possible to find disk IOs for a Query?
  • From: Bobby Mozumder
• Re: pgsql-performance issue
  • From: Andres Freund
• Re: Slow query with big tables
  • From: Tommi Kaksonen
• Re: Slow query with big tables
  • From: Jeff Janes
• Re: Slow query with big tables
  • From: Jeff Janes
• Re: Slow query with big tables
  • From: Tom Lane
• Re: Slow query with big tables
  • From: Craig James
• Re: Slow query with big tables
  • From: Pavel Stehule
• Re: Slow query with big tables
  • From: Jim Nasby
• Re: Slow query with big tables
  • From: Mike Sofen
• Re: Slow query with big tables
  • From: Tommi K
• Re: Slow query with big tables
  • From: Craig James
• Re: Slow query with big tables
  • From: Tommi K
• Re: Slow query with big tables
  • From: Andreas Kretschmer
• Slow query with big tables
  • From: Tommi Kaksonen
• Re: pgsql-performance issue
  • From: debasis . moharana
• Re: pgsql-performance issue
  • From: Pavel Stehule
• Re: pgsql-performance issue
  • From: debasis . moharana
• Re: pgsql-performance issue
  • From: Pavel Stehule
• Re: pgsql-performance issue
  • From: debasis . moharana
• Re: pgsql-performance issue
  • From: Pavel Stehule
• Re: pgsql-performance issue
  • From: debasis . moharana
• Re: pgsql-performance issue
  • From: Pavel Stehule
• pgsql-performance issue
  • From: debasis . moharana
• pgsql-performance issue
  • From: debasis . moharana
• Re: Big data INSERT optimization - ExclusiveLock on extension of the table
  • From: Merlin Moncure
• Re: Re: Big data INSERT optimization - ExclusiveLock on extension of the table
  • From: Jim Nasby
• Re: Estimates on partial index
  • From: Victor Yegorov
• Re: Estimates on partial index
  • From: Victor Yegorov
• Re: Estimates on partial index
  • From: Ashish Kumar Singh
• Re: Big data INSERT optimization - ExclusiveLock on extension of the table
  • From: pinker
• Re: Estimates on partial index
  • From: Jim Nasby
• Re: Big data INSERT optimization - ExclusiveLock on extension of the table
  • From: Jim Nasby
• Re: Estimates on partial index
  • From: Jeff Janes
• Re: Estimates on partial index
  • From: Victor Yegorov
• Re: Estimates on partial index
  • From: Victor Yegorov
• Re: Estimates on partial index
  • From: Jeff Janes
• Re: Estimates on partial index
  • From: Tom Lane
• Estimates on partial index
  • From: Victor Yegorov
• Big data INSERT optimization - ExclusiveLock on extension of the table
  • From: pinker
• Re: what's the slowest part in the SQL
  • From: Merlin Moncure
• Re: index fragmentation on insert-only table with non-unique column
  • From: Claudio Freire
• Re: index fragmentation on insert-only table with non-unique column
  • From: Justin Pryzby
• Re: Planner do seq scan on empty master partitioned table
  • From: Vladimir Borodin
• Re: Planner do seq scan on empty master partitioned table
  • From: Tom Lane
• Planner do seq scan on empty master partitioned table
  • From: Andrey Zhidenkov
• Re: what's the slowest part in the SQL
  • From: Claudio Freire
• Re: Logging queries using sequential scans
  • From: Pavel Stehule
• Logging queries using sequential scans
  • From: Ivan Voras
• Re: what's the slowest part in the SQL
  • From: Suya Huang
• Re: what's the slowest part in the SQL
  • From: Tom Lane
• Re: what's the slowest part in the SQL
  • From: Suya Huang
• Re: what's the slowest part in the SQL
  • From: Suya Huang
• Re: what's the slowest part in the SQL
  • From: Claudio Freire
• Re: what's the slowest part in the SQL
  • From: Claudio Freire
• Re: what's the slowest part in the SQL
  • From: Tom Lane
• Re: what's the slowest part in the SQL
  • From: Suya Huang
• Re: what's the slowest part in the SQL
  • From: Claudio Freire
• Re: what's the slowest part in the SQL
  • From: Suya Huang
• Re: what's the slowest part in the SQL
  • From: Claudio Freire
• what's the slowest part in the SQL
  • From: Suya Huang
• Re: Create language plperlu Error
  • From: Gerardo Herzig
• Re: Create language plperlu Error
  • From: Om Prakash Jaiswal
• Re: Create language plperlu Error
  • From: Johan Fredriksson
• Need Beta Users for New Database Monitoring Solution!
  • From: jonescam
• Re: Very poor performance with Nested Loop Anti Join
  • From: Andreas Joseph Krogh
• Create language plperlu Error
  • From: Om Prakash Jaiswal
• Re: Very poor performance with Nested Loop Anti Join
  • From: Tom Lane
• Re: Very poor performance with Nested Loop Anti Join
  • From: Andreas Joseph Krogh
• Very poor performance with Nested Loop Anti Join
  • From: Andreas Joseph Krogh
• Re: PostgreSQL on ZFS: performance tuning
  • From: trafdev
• Re: PostgreSQL on ZFS: performance tuning
  • From: Tomas Vondra
• PostgreSQL on ZFS: performance tuning
  • From: trafdev
• Re: Very slow query (3-4mn) on a table with 25millions rows
  • From: Abadie Lana
• Re: Very slow query (3-4mn) on a table with 25millions rows
  • From: Abadie Lana
• Re: Very slow query (3-4mn) on a table with 25millions rows
  • From: Félix GERZAGUET
• Re: Very slow query (3-4mn) on a table with 25millions rows
  • From: Félix GERZAGUET
• Re: Very slow query (3-4mn) on a table with 25millions rows
  • From: Abadie Lana
• Re: Very slow query (3-4mn) on a table with 25millions rows
  • From: Martín Marqués
• Re: Very slow query (3-4mn) on a table with 25millions rows
  • From: Abadie Lana
• Re: Very slow query (3-4mn) on a table with 25millions rows
  • From: Tom Lane
• Very slow query (3-4mn) on a table with 25millions rows
  • From: Abadie Lana
• Re: Seeing execution plan of foreign key constraint check?
  • From: Jim Nasby
• Re: [PERFORMANCE] Performance index and table
  • From: Tom Lane
• [PERFORMANCE] Performance index and table
  • From: Oscar Camuendo
• Re: Seeing execution plan of foreign key constraint check?
  • From: Robert Klemme
• Re: Performance problems with 9.2.15
  • From: Johan Fredriksson
• Re: Performance problems with 9.2.15
  • From: Mark Kirkwood
• Re: Performance problems with 9.2.15
  • From: Johan Fredriksson
• Re: Performance problems with 9.2.15
  • From: Johan Fredriksson
• Re: less than 2 sec for response - possible?
  • From: Jim Nasby
• Re: Seeing execution plan of foreign key constraint check?
  • From: Jim Nasby
• Re: Seeing execution plan of foreign key constraint check?
  • From: Tom Lane
• Re: Seeing execution plan of foreign key constraint check?
  • From: Jim Nasby
• Re: Performance problems with 9.2.15
  • From: Claudio Freire
• Re: Performance problems with 9.2.15
  • From: David G. Johnston
• Re: Performance problems with 9.2.15
  • From: Claudio Freire
• Re: Performance problems with 9.2.15
  • From: Johan Fredriksson
• Poor choice of backward scan
  • From: Jim Nasby
• Re: Seeing execution plan of foreign key constraint check?
  • From: Tom Lane
• Re: less than 2 sec for response - possible?
  • From: trafdev
• Re: Random slow queries
  • From: Jim Nasby
• Re: Seeing execution plan of foreign key constraint check?
  • From: Jim Nasby
• Re: less than 2 sec for response - possible?
  • From: Jim Nasby
• Re: less than 2 sec for response - possible?
  • From: trafdev
• Re: DELETE takes too much memory
  • From: Jim Nasby
• Re: less than 2 sec for response - possible?
  • From: Jim Nasby
• Re: slony rpm help slony1-95-2.2.2-1.rhel6.x86_64
  • From: Jan Wieck
• Re: [HACKERS] [PERFORM] 9.4 -> 9.5 regression with queries through pgbouncer on RHEL 6
  • From: Dmitriy Sarafannikov
• Re: [HACKERS] 9.4 -> 9.5 regression with queries through pgbouncer on RHEL 6
  • From: Andres Freund
• Re: [HACKERS] 9.4 -> 9.5 regression with queries through pgbouncer on RHEL 6
  • From: Andres Freund
• Re: pgtune or similar to assist in initial settings
  • From: Imre Samu
• pgtune or similar to assist in initial settings
  • From: Tory M Blue
• Re: less than 2 sec for response - possible?
  • From: trafdev
• Re: Capacitors, etc., in hard drives and SSD for DBMS machines...
  • From: Jean-David Beyer
• Re: Capacitors, etc., in hard drives and SSD for DBMS machines...
  • From: Wes Vaske (wvaske)
• Re: Capacitors, etc., in hard drives and SSD for DBMS machines...
  • From: vincent
• Re: Capacitors, etc., in hard drives and SSD for DBMS machines...
  • From: Karl Denninger
• Re: Capacitors, etc., in hard drives and SSD for DBMS machines...
  • From: Thomas Samson
• Re: Capacitors, etc., in hard drives and SSD for DBMS machines...
  • From: Levente Birta
• Capacitors, etc., in hard drives and SSD for DBMS machines...
  • From: Jean-David Beyer
• Re: Tuning guidelines for server with 256GB of RAM and SSDs?
  • From: Mark Kirkwood
• Re: Tuning guidelines for server with 256GB of RAM and SSDs?
  • From: Kaixi Luo
• Re: Tuning guidelines for server with 256GB of RAM and SSDs?
  • From: Scott Marlowe
• Re: Tuning guidelines for server with 256GB of RAM and SSDs?
  • From: Merlin Moncure
• Re: Tuning guidelines for server with 256GB of RAM and SSDs?
  • From: Wes Vaske (wvaske)
• Re: Tuning guidelines for server with 256GB of RAM and SSDs?
  • From: Kaixi Luo
• Re: DELETE takes too much memory
  • From: Kouber Saparev
• Re: Tuning guidelines for server with 256GB of RAM and SSDs?
  • From: Mark Kirkwood
• Re: Tuning guidelines for server with 256GB of RAM and SSDs?
  • From: Wes Vaske (wvaske)
• Re: Tuning guidelines for server with 256GB of RAM and SSDs?
  • From: Scott Marlowe
• Re: Tuning guidelines for server with 256GB of RAM and SSDs?
  • From: Merlin Moncure
• Re: less than 2 sec for response - possible?
  • From: trafdev
• Re: DELETE takes too much memory
  • From: Merlin Moncure
• Re: less than 2 sec for response - possible?
  • From: Torsten Zuehlsdorff
• Re: less than 2 sec for response - possible?
  • From: trafdev
• Re: less than 2 sec for response - possible?
  • From: Torsten Zuehlsdorff
• Re: DELETE takes too much memory
  • From: Kouber Saparev
• Re: Tuning guidelines for server with 256GB of RAM and SSDs?
  • From: Mkrtchyan, Tigran
• Re: DELETE takes too much memory
  • From: Josh Berkus
• Re: less than 2 sec for response - possible?
  • From: trafdev
• Tuning guidelines for server with 256GB of RAM and SSDs?
  • From: Kaixi Luo
• Seeing execution plan of foreign key constraint check?
  • From: Robert Klemme
• Re: less than 2 sec for response - possible?
  • From: Torsten Zuehlsdorff
• Re: less than 2 sec for response - possible?
  • From: Pujol Mathieu
• Re: DELETE takes too much memory
  • From: Kouber Saparev
• Re: DELETE takes too much memory
  • From: Alvaro Herrera
• DELETE takes too much memory
  • From: Kouber Saparev
• Re: [HACKERS] 9.4 -> 9.5 regression with queries through pgbouncer on RHEL 6
  • From: Vladimir Borodin
• Re: Random slow queries
  • From: devel . brain99
• Re: less than 2 sec for response - possible?
  • From: trafdev
• Re: less than 2 sec for response - possible?
  • From: Tom Lane
• less than 2 sec for response - possible?
  • From: trafdev
• Re: pg_xlog dir not getting swept
  • From: Niels Kristian Schjødt
• Re: Random slow queries
  • From: Tom Lane
• Re: Random slow queries
  • From: Jeff Janes
• Re: Random slow queries
  • From: Tom Lane
• Re: pg_xlog dir not getting swept
  • From: Jeff Janes
• Re: Random slow queries
  • From: devel . brain99
• Re: Random slow queries
  • From: devel . brain99
• Re: Random slow queries
  • From: Igor Neyman
• Re: Random slow queries
  • From: Kevin Grittner
• pg_xlog dir not getting swept
  • From: Niels Kristian Schjødt
• Random slow queries
  • From: devel . brain99
• [PERFORM] Cache performance decreases
  • From: Suren Arustamyan
• Re: can't explain commit performance win7 vs linux : 8000/s vs 419/s
  • From: Imre Samu
• Re: can't explain commit performance win7 vs linux : 8000/s vs 419/s
  • From: Jeff Janes
• Re: can't explain commit performance win7 vs linux : 8000/s vs 419/s
  • From: Tom Lane
• can't explain commit performance win7 vs linux : 8000/s vs 419/s
  • From: t.dalpozzo@xxxxxxxxx
• Re: Can't get two index scans
  • From: Craig James
• Re: Can't get two index scans
  • From: Jeff Janes
• Re: Can't get two index scans
  • From: Craig James
• Re: Can't get two index scans
  • From: Jeff Janes
• Can't get two index scans
  • From: Craig James
• Looking for more Beta Users!
  • From: jonescam
• Re: Savepoint and Releasepoint in Logs
  • From: Jeff Janes
• Re: Index not used
  • From: meike . talbach
• Re: 9.6 query slower than 9.5.3
  • From: Tom Lane
• Savepoint and Releasepoint in Logs
  • From: e.ratnakar.shetty
• Re: 9.6 query slower than 9.5.3
  • From: Adam Brusselback
• Re: Indexes for hashes
  • From: julyanto SUTANDANG
• Re: Indexes for hashes
  • From: Ivan Voras
• Re: Indexes for hashes
  • From: Claudio Freire
• Re: Indexes for hashes
  • From: julyanto SUTANDANG
• Re: 9.6 query slower than 9.5.3
  • From: Adam Brusselback
• Re: 9.6 query slower than 9.5.3
  • From: Tom Lane
• Re: Indexes for hashes
  • From: Claudio Freire
• Re: 9.6 query slower than 9.5.3
  • From: Adam Brusselback
• Re: 9.6 query slower than 9.5.3
  • From: Tom Lane
• Re: 9.6 query slower than 9.5.3
  • From: Adam Brusselback
• Re: 9.6 query slower than 9.5.3
  • From: Adam Brusselback
• Re: 9.6 query slower than 9.5.3
  • From: Tom Lane
• 9.6 query slower than 9.5.3
  • From: Adam Brusselback
• Re: Index not used
  • From: David G. Johnston
• Re: Index not used
  • From: Tom Lane
• Re: Index not used
  • From: John Gorman
• Re: Many-to-many performance problem
  • From: Rowan Seymour
• Index not used
  • From: meike . talbach
• Re: pg_restore seems very slow
  • From: Adam Scott
• Re: pg_restore seems very slow
  • From: Adrian Myers
• Re: pg_restore seems very slow
  • From: David G. Johnston
• pg_restore seems very slow
  • From: Adrian Myers
• Re: Indexes for hashes
  • From: Jeff Janes
• Re: Indexes for hashes
  • From: ktm@xxxxxxxx
• Re: Indexes for hashes
  • From: Joshua D. Drake
• Re: Indexes for hashes
  • From: Ivan Voras
• Re: Indexes for hashes
  • From: Ivan Voras
• Re: Indexes for hashes
  • From: julyanto SUTANDANG
• Re: Indexes for hashes
  • From: Ivan Voras
• Re: Indexes for hashes
  • From: hubert depesz lubaczewski
• Re: Indexes for hashes
  • From: ktm@xxxxxxxx
• Re: Indexes for hashes
  • From: Ivan Voras
• Re: Indexes for hashes
  • From: ktm@xxxxxxxx
• Re: Indexes for hashes
  • From: Torsten Zuehlsdorff
• Indexes for hashes
  • From: Ivan Voras
• Re: Clarification on using pg_upgrade
  • From: Tory M Blue
• Re: Clarification on using pg_upgrade
  • From: Jim Nasby
• Re: pg_database_size
  • From: Jim Nasby
• Re: 9.4 -> 9.5 regression with queries through pgbouncer on RHEL 6
  • From: Andres Freund
• Re: Many-to-many performance problem
  • From: Alex Ignatov
• Re: Many-to-many performance problem
  • From: Tom Lane
• Re: Many-to-many performance problem
  • From: Yves Dorfsman
• Re: Many-to-many performance problem
  • From: Tom Lane
• Many-to-many performance problem
  • From: Rowan Seymour
• Re: 9.4 -> 9.5 regression with queries through pgbouncer on RHEL 6
  • From: Andres Freund
• Re: array size exceeds the maximum allowed (1073741823) when building a json
  • From: Merlin Moncure
• Re: Performance of LIKE/NOT LIKE when used in single query
  • From: Jeff Janes
• Re: array size exceeds the maximum allowed (1073741823) when building a json
  • From: Nicolas Paris
• Re: array size exceeds the maximum allowed (1073741823) when building a json
  • From: Merlin Moncure
• Re: Combination of partial and full indexes
  • From: Rafał Gutkowski
• Re: Combination of partial and full indexes
  • From: Rafał Gutkowski
• Re: array size exceeds the maximum allowed (1073741823) when building a json
  • From: Tom Lane
• Re: array size exceeds the maximum allowed (1073741823) when building a json
  • From: Michael Paquier
• Re: Performance of LIKE/NOT LIKE when used in single query
  • From: David G. Johnston
• Performance of LIKE/NOT LIKE when used in single query
  • From: Ed Felstein
• Re: 9.4 -> 9.5 regression with queries through pgbouncer on RHEL 6
  • From: Антон Бушмелев
• Re: array size exceeds the maximum allowed (1073741823) when building a json
  • From: Nicolas Paris
• Re: Combination of partial and full indexes
  • From: Gerardo Herzig
• Combination of partial and full indexes
  • From: Rafał Gutkowski
• Re: Locking concurrency: select for update vs update
  • From: Streamsoft - Mirek Szajowski
• Re: Locking concurrency: select for update vs update
  • From: Tom Lane
• Re: array size exceeds the maximum allowed (1073741823) when building a json
  • From: Josh Berkus
• Re: array size exceeds the maximum allowed (1073741823) when building a json
  • From: David G. Johnston
• Re: array size exceeds the maximum allowed (1073741823) when building a json
  • From: Nicolas Paris
• Re: array size exceeds the maximum allowed (1073741823) when building a json
  • From: David G. Johnston
• Re: array size exceeds the maximum allowed (1073741823) when building a json
  • From: Nicolas Paris
• Re: array size exceeds the maximum allowed (1073741823) when building a json
  • From: David G. Johnston
• array size exceeds the maximum allowed (1073741823) when building a json
  • From: Nicolas Paris
• Re: Locking concurrency: select for update vs update
  • From: Streamsoft - Mirek Szajowski
• Re: Locking concurrency: select for update vs update
  • From: Szymon Lipiński
• Locking concurrency: select for update vs update
  • From: Streamsoft - Mirek Szajowski
• Re: index fragmentation on insert-only table with non-unique column
  • From: Jeff Janes
• Re: index fragmentation on insert-only table with non-unique column
  • From: Tom Lane
• Re: index fragmentation on insert-only table with non-unique column
  • From: Kevin Grittner
• Re: pg_database_size
  • From: Venkata Balaji N
• pg_database_size
  • From: sangeetha
• Re: index fragmentation on insert-only table with non-unique column
  • From: Claudio Freire
• Re: index fragmentation on insert-only table with non-unique column
  • From: Justin Pryzby
• slony rpm help slony1-95-2.2.2-1.rhel6.x86_64
  • From: avi Singh
• Re: index fragmentation on insert-only table with non-unique column
  • From: Claudio Freire
• Re: similarity and operator '%'
  • From: Jeff Janes
• Re: Re: Planner chooses slow index heap scan despite accurate row estimates
  • From: Jeff Janes
• Re: similarity and operator '%'
  • From: David G. Johnston
• similarity and operator '%'
  • From: Volker Boehm
• Re: Performance problems with 9.2.15
  • From: Johan Fredriksson
• Re: Performance problems with 9.2.15
  • From: Johan Fredriksson
• Re: Planner chooses slow index heap scan despite accurate row estimates
  • From: Jake Magner
• Re: Re: Planner chooses slow index heap scan despite accurate row estimates
  • From: Tom Lane
• Re: Planner chooses slow index heap scan despite accurate row estimates
  • From: Jake Magner
• Re: Planner chooses slow index heap scan despite accurate row estimates
  • From: Tom Lane
• Planner chooses slow index heap scan despite accurate row estimates
  • From: Jake Magner
• Re: Performance problems with 9.2.15
  • From: Steve Crawford
• Re: Performance problems with 9.2.15
  • From: Johan Fredriksson
• Re: Performance problems with 9.2.15
  • From: Tom Lane
• Performance problems with 9.2.15
  • From: Johan Fredriksson
• Re: Testing in AWS, EBS
  • From: Rayson Ho
• Re: Testing in AWS, EBS
  • From: Yves Dorfsman
• Re: Testing in AWS, EBS
  • From: Artem Tomyuk
• Re: Testing in AWS, EBS
  • From: Rayson Ho
• Re: Testing in AWS, EBS
  • From: Artem Tomyuk
• Re: Testing in AWS, EBS
  • From: Rayson Ho
• Re: Testing in AWS, EBS
  • From: Artem Tomyuk
• Re: Testing in AWS, EBS
  • From: Rayson Ho
• Re: Testing in AWS, EBS
  • From: Artem Tomyuk
• Re: Testing in AWS, EBS
  • From: Yves Dorfsman
• Re: Testing in AWS, EBS
  • From: Artem Tomyuk
• Re: Testing in AWS, EBS
  • From: Rayson Ho
• Re: Testing in AWS, EBS
  • From: Yves Dorfsman
• Re: Testing in AWS, EBS
  • From: Rayson Ho
• Testing in AWS, EBS
  • From: Tory M Blue
• 9.4 -> 9.5 regression with queries through pgbouncer on RHEL 6
  • From: Vladimir Borodin
• Re: index fragmentation on insert-only table with non-unique column
  • From: Justin Pryzby
• Re: index fragmentation on insert-only table with non-unique column
  • From: Justin Pryzby
• Re: index fragmentation on insert-only table with non-unique column
  • From: Jeff Janes
• Re: index fragmentation on insert-only table with non-unique column
  • From: Peter Geoghegan
• Re: index fragmentation on insert-only table with non-unique column
  • From: Tom Lane
• Re: index fragmentation on insert-only table with non-unique column
  • From: Stephen Frost
• Re: index fragmentation on insert-only table with non-unique column
  • From: Peter Geoghegan
• index fragmentation on insert-only table with non-unique column
  • From: Justin Pryzby
• Locks when launching function across schemata
  • From: Christian Castelli
• Re: Database transaction with intermittent slow responses
  • From: John Gorman
• Re: Database transaction with intermittent slow responses
  • From: Robert Klemme
• Re: Database transaction with intermittent slow responses
  • From: Gerardo Herzig
• Re: Database transaction with intermittent slow responses
  • From: John Gorman
• Re: Database transaction with intermittent slow responses
  • From: Gerardo Herzig
• Database transaction with intermittent slow responses
  • From: John Gorman
• Re: LIKE pattern
  • From: Tom Lane
• Re: LIKE pattern
  • From: Jeff Janes
• Re: LIKE pattern
  • From: Robert Klemme
• Re: LIKE pattern
  • From: SoDupuDupu
• LIKE pattern
  • From: Владимир
• Re: Poor disk (virtio) Performance Inside KVM virt-machine vs host machine
  • From: Merlin Moncure
• Re: Poor disk (virtio) Performance Inside KVM virt-machine vs host machine
  • From: Alan Hodgson
• Re: Poor disk (virtio) Performance Inside KVM virt-machine vs host machine
  • From: Artem Tomyuk
• Re: Poor disk (virtio) Performance Inside KVM virt-machine vs host machine
  • From: Michael Nolan
• Re: Poor disk (virtio) Performance Inside KVM virt-machine vs host machine
  • From: Imre Samu
• Poor disk (virtio) Performance Inside KVM virt-machine vs host machine
  • From: Artem Tomyuk
• Re: Performance problems with postgres and null Values?
  • From: Sven Kerkling
• Re: Performant queries on table with many boolean columns
  • From: Adam Brusselback
• Re: Performant queries on table with many boolean columns
  • From: Merlin Moncure
• Re: Performance problems with postgres and null Values?
  • From: Albe Laurenz
• Re: Performance problems with postgres and null Values?
  • From: Sven Kerkling
• Re: Performant queries on table with many boolean columns
  • From: bricklen
• Re: Performant queries on table with many boolean columns
  • From: bricklen
• Re: Performance problems with postgres and null Values?
  • From: Merlin Moncure
• Re: Performant queries on table with many boolean columns
  • From: Rob Imig
• Re: Performant queries on table with many boolean columns
  • From: Rob Imig
• Re: Performant queries on table with many boolean columns
  • From: Jeff Janes
• Re: Performant queries on table with many boolean columns
  • From: Jeff Janes
• Re: Performant queries on table with many boolean columns
  • From: David G. Johnston
• Re: Performant queries on table with many boolean columns
  • From: Teodor Sigaev
• Performance problems with postgres and null Values?
  • From: Sven Kerkling
• Re: Performant queries on table with many boolean columns
  • From: David G. Johnston
• Re: Performant queries on table with many boolean columns
  • From: Rick Otten
• Re: Performant queries on table with many boolean columns
  • From: Teodor Sigaev
• Performant queries on table with many boolean columns
  • From: Rob Imig
• Re: Clarification on using pg_upgrade
  • From: Tory M Blue
• Re: Hash join seq scan slow
  • From: Jeff Janes
• Hash join seq scan slow
  • From: Aldo Sarmiento
• Re: Slow update on column that is part of exclusion constraint
  • From: Evgeniy Shishkin
• Re: Slow update on column that is part of exclusion constraint
  • From: Adam Brusselback
• Re: Slow update on column that is part of exclusion constraint
  • From: Evgeniy Shishkin
• Re: Slow update on column that is part of exclusion constraint
  • From: Adam Brusselback
• Slow update on column that is part of exclusion constraint
  • From: Adam Brusselback
• Re: Adding a ROLLUP switches to GroupAggregate unexpectedly
  • From: Peter Geoghegan
• Re: Big number of connections
  • From: Pavel Stehule
• Re: Big number of connections
  • From: Artem Tomyuk
• Re: Big number of connections
  • From: Moreno Andreo
• Re: Big number of connections
  • From: Artem Tomyuk
• Re: Big number of connections
  • From: Moreno Andreo
• Re: Big number of connections
  • From: Pavel Stehule
• Re: Big number of connections
  • From: Mike Sofen
• Re: Big number of connections
  • From: Jim Nasby
• Re: Clarification on using pg_upgrade
  • From: Jim Nasby
• Re: Searching GIN-index (FTS) and sort by timestamp-column
  • From: Jeff Janes
• Re: Fast HashJoin only after a cluster/recreate table
  • From: Alexandre de Arruda Paes
• Re: Fast HashJoin only after a cluster/recreate table
  • From: David Rowley
• Re: Big number of connections
  • From: jarek
• Fast HashJoin only after a cluster/recreate table
  • From: Alexandre de Arruda Paes
• Re: Big number of connections
  • From: Karl Denninger
• Re: Big number of connections
  • From: Chris Cogdon
• Re: Big number of connections
  • From: Alvaro Herrera
• Re: Big number of connections
  • From: Andrew Dunstan
• Re: Big number of connections
  • From: Igor Neyman
• Big number of connections
  • From: Jarek
• Re: Adding a ROLLUP switches to GroupAggregate unexpectedly
  • From: ktm@xxxxxxxx
• Re: Adding a ROLLUP switches to GroupAggregate unexpectedly
  • From: Tom Lane
• Adding a ROLLUP switches to GroupAggregate unexpectedly
  • From: Chris Cogdon
• Re: Query not using Index
  • From: Jeff Janes
• Re: Query not using Index
  • From: Wei Shan
• Re: Query not using Index
  • From: Andreas Kretschmer
• Query not using Index
  • From: Wei Shan
• Re: Clarification on using pg_upgrade
  • From: Tory M Blue
• Re: [SPAM] Re: Architectural question
  • From: Moreno Andreo
• Re: [SPAM] Re: Architectural question
  • From: Jim Nasby
• Re: Architectural question
  • From: Moreno Andreo
• Re: Architectural question
  • From: Rick Otten
• Re: Architectural question
  • From: Mike Sofen
• Re: Architectural question
  • From: Moreno Andreo
• Re: Architectural question
  • From: Thomas Kellerer
• Re: [SPAM] Re: Architectural question
  • From: Moreno Andreo
• Re: Searching GIN-index (FTS) and sort by timestamp-column
  • From: Oleg Bartunov
• Re: Disk Benchmarking Question
  • From: Dave Stibrany
• Re: Searching GIN-index (FTS) and sort by timestamp-column
  • From: Andreas Joseph Krogh
• Re: Searching GIN-index (FTS) and sort by timestamp-column
  • From: Oleg Bartunov
• Re: Searching GIN-index (FTS) and sort by timestamp-column
  • From: Andreas Joseph Krogh
• Re: Performance decline maybe caused by multi-column index?
  • From: Jeff Janes
• Re: Disk Benchmarking Question
  • From: Scott Marlowe
• Re: Disk Benchmarking Question
  • From: Scott Marlowe
• Re: Disk Benchmarking Question
  • From: Mike Sofen
• Re: Searching GIN-index (FTS) and sort by timestamp-column
  • From: Jeff Janes
• Re: [GENERAL] grant select on pg_stat_activity
  • From: Adrian Klaver
• grant select on pg_stat_activity
  • From: avi Singh
• Re: Disk Benchmarking Question
  • From: Dave Stibrany
• Performance decline maybe caused by multi-column index?
  • From: Jan Bauer Nielsen
• Re: using shared_buffers during seq_scan
  • From: Albe Laurenz
• Re: Disk Benchmarking Question
  • From: Mike Sofen
• Disk Benchmarking Question
  • From: Dave Stibrany
• Re: Searching GIN-index (FTS) and sort by timestamp-column
  • From: Tom Lane
• Re: Searching GIN-index (FTS) and sort by timestamp-column
  • From: Andreas Joseph Krogh
• Re: Searching GIN-index (FTS) and sort by timestamp-column
  • From: Tom Lane
• Re: using shared_buffers during seq_scan
  • From: Rick Otten
• using shared_buffers during seq_scan
  • From: Artem Tomyuk
• Re: Nested Loop vs Hash Join based on predicate?
  • From: Pavel Stehule
• Nested Loop vs Hash Join based on predicate?
  • From: Doiron, Daniel
• Re: Searching GIN-index (FTS) and sort by timestamp-column
  • From: Andreas Joseph Krogh
• Re: Searching GIN-index (FTS) and sort by timestamp-column
  • From: Andreas Joseph Krogh
• Re: Searching GIN-index (FTS) and sort by timestamp-column
  • From: Evgeniy Shishkin
• Re: Searching GIN-index (FTS) and sort by timestamp-column
  • From: Evgeniy Shishkin
• Re: Searching GIN-index (FTS) and sort by timestamp-column
  • From: Evgeniy Shishkin
• Re: Searching GIN-index (FTS) and sort by timestamp-column
  • From: Andreas Joseph Krogh
• Re: Searching GIN-index (FTS) and sort by timestamp-column
  • From: Andreas Joseph Krogh
• Re: Searching GIN-index (FTS) and sort by timestamp-column
  • From: Tom Lane
• Searching GIN-index (FTS) and sort by timestamp-column
  • From: Andreas Joseph Krogh
• Re: Merge joins on index scans
  • From: Tom Lane
• Re: DIsk I/O from pg_stat_activity
  • From: Vladimir Borodin
• DIsk I/O from pg_stat_activity
  • From: Artem Tomyuk
• Re: Clarification on using pg_upgrade
  • From: Jim Nasby
• Re: Architectural question
  • From: Jim Nasby
• Re: using stale statistics instead of current ones because stats collector is not responding
  • From: Tomas Vondra
• using stale statistics instead of current ones because stats collector is not responding
  • From: Tory M Blue
• Re: Odd behavior with indices
  • From: Tom Lane
• Re: Clarification on using pg_upgrade
  • From: Justin Pryzby
• Clarification on using pg_upgrade
  • From: Tory M Blue
• Re: Odd behavior with indices
  • From: Merlin Moncure
• Re: [ADMIN] autovacuum disk IO
  • From: Jehan-Guillaume de Rorthais
• Re: [SPAM] Re: autovacuum disk IO
  • From: Moreno Andreo
• Re: [SPAM] Re: autovacuum disk IO
  • From: Alvaro Herrera
• Re: [SPAM] Re: autovacuum disk IO
  • From: Scott Marlowe
• Re: [SPAM] Re: autovacuum disk IO
  • From: Moreno Andreo
• Re: autovacuum disk IO
  • From: Scott Marlowe
• Re: autovacuum disk IO
  • From: Scott Marlowe
• Re: autovacuum disk IO
  • From: Pavel Stehule
• autovacuum disk IO
  • From: Artem Tomyuk
• Re: Merge joins on index scans
  • From: James Parks
• Re: Merge joins on index scans
  • From: Tom Lane
• Re: Odd behavior with indices
  • From: Tom Lane
• Re: Odd behavior with indices
  • From: Matheus de Oliveira
• Re: Merge joins on index scans
  • From: David Rowley
• Merge joins on index scans
  • From: James Parks
• Re: Odd behavior with indices
  • From: joe meiring
• Re: Odd behavior with indices
  • From: David G. Johnston
• Odd behavior with indices
  • From: joe meiring
• Re: Odd behavior with indices
  • From: David G. Johnston
• Re: Filesystem and Disk Partitioning for New Server Setup
  • From: Wes Vaske (wvaske)
• Re: Filesystem and Disk Partitioning for New Server Setup
  • From: Rick Otten
• Re: Filesystem and Disk Partitioning for New Server Setup
  • From: Dave Stibrany
• Fwd: Filesystem and Disk Partitioning for New Server Setup
  • From: Rick Otten
• Fwd: Cloud versus buying my own iron
  • From: Rick Otten
• Re: Cloud versus buying my own iron
  • From: Gunnar "Nick" Bluth
• Cloud versus buying my own iron
  • From: Craig James
• Filesystem and Disk Partitioning for New Server Setup
  • From: dstibrany
• Re: [SPAM] Re: Architectural question
  • From: Moreno Andreo
• Re: Why Postgres use a little memory on Windows.
  • From: tuanhoanganh
• Re: Why Postgres use a little memory on Windows.
  • From: Jeff Janes
• Re: [GENERAL] Why Postgres use a little memory on Windows.
  • From: Adrian Klaver
• Re: [GENERAL] Why Postgres use a little memory on Windows.
  • From: Francisco Olarte
• Re: [GENERAL] Why Postgres use a little memory on Windows.
  • From: Francisco Olarte
• Re: [GENERAL] Why Postgres use a little memory on Windows.
  • From: Tom Lane
• Re: [GENERAL] Why Postgres use a little memory on Windows.
  • From: Adrian Klaver
• Why Postgres use a little memory on Windows.
  • From: tuanhoanganh
• Re: Architectural question
  • From: Jim Nasby
• Re: Primary key index suddenly became very slow
  • From: Venkata Balaji N
• Re: Primary key index suddenly became very slow
  • From: jaime soler
• Re: Running lots of inserts from selects on 9.4.5
  • From: Dan Langille
• Re: Running lots of inserts from selects on 9.4.5
  • From: Dan Langille
• Re: Running lots of inserts from selects on 9.4.5
  • From: Dan Langille
• Architectural question
  • From: Moreno Andreo
• Re: Running lots of inserts from selects on 9.4.5
  • From: Dan Langille
• Re: Running lots of inserts from selects on 9.4.5
  • From: Jeff Janes
• Running lots of inserts from selects on 9.4.5
  • From: Dan Langille
• Re: bad COPY performance with NOTIFY in a trigger
  • From: Merlin Moncure
• Re: gin performance issue.
  • From: Jeff Janes
• Re: Bitmap and-ing between btree and gin?
  • From: Jeff Janes
• Re: bad COPY performance with NOTIFY in a trigger
  • From: Merlin Moncure
• Re: gin performance issue.
  • From: Marc Mamin
• Re: Primary key index suddenly became very slow
  • From: Gustav Karlsson
• Primary key index suddenly became very slow
  • From: Gustav Karlsson
• Re: PostgreSQL seems to create inefficient plans in simple conditional joins
  • From: Hedayat Vatankhah
• Re: bad COPY performance with NOTIFY in a trigger
  • From: Filip Rembiałkowski
• Re: bad COPY performance with NOTIFY in a trigger
  • From: Merlin Moncure
• Re: View containing a recursive function
  • From: Mathieu De Zutter
• Re: bad COPY performance with NOTIFY in a trigger
  • From: Filip Rembiałkowski
• Re: gin performance issue.
  • From: Tom Lane
• Re: bad COPY performance with NOTIFY in a trigger
  • From: Filip Rembiałkowski
• gin performance issue.
  • From: Marc Mamin
• Re: bad COPY performance with NOTIFY in a trigger
  • From: Harald Fuchs
• Re: bad COPY performance with NOTIFY in a trigger
  • From: Tom Lane
• bad COPY performance with NOTIFY in a trigger
  • From: Filip Rembiałkowski
• Re: Bitmap and-ing between btree and gin?
  • From: Jordi
• Re: Bitmap and-ing between btree and gin?
  • From: Tom Lane
• Bitmap and-ing between btree and gin?
  • From: Jordi
• Understanding ANALYZE memory usage with "big" tsvector columns
  • From: Jérôme Augé
• Re: Hash join gets slower as work_mem increases?
  • From: Albe Laurenz
• Re: Hash join gets slower as work_mem increases?
  • From: Tomas Vondra
• Re: View containing a recursive function
  • From: Tom Lane
• Re: Hash join gets slower as work_mem increases?
  • From: Albe Laurenz
• View containing a recursive function
  • From: Mathieu De Zutter
• Re: PostgreSQL seems to create inefficient plans in simple conditional joins
  • From: Hedayat Vatankhah
• Re: PostgreSQL seems to create inefficient plans in simple conditional joins
  • From: Vitalii Tymchyshyn
• Re: PostgreSQL seems to create inefficient plans in simple conditional joins
  • From: David Rowley
• Re: PostgreSQL seems to create inefficient plans in simple conditional joins
  • From: Vitalii Tymchyshyn
• Re: PostgreSQL seems to create inefficient plans in simple conditional joins
  • From: David Rowley
• Re: Hash join gets slower as work_mem increases?
  • From: Tomas Vondra
• PostgreSQL seems to create inefficient plans in simple conditional joins
  • From: Hedayat Vatankhah
• Re: jsonb_agg performance
  • From: Andrew Dunstan
• jsonb_agg performance
  • From: jfleming
• Re: Hash join gets slower as work_mem increases?
  • From: Pavel Stehule
• Hash join gets slower as work_mem increases?
  • From: Albe Laurenz
• Re: Postgres partitions-query scanning all child tables
  • From: rverghese
• Re: Postgres partitions-query scanning all child tables
  • From: Corey Huinker
• Re: Postgres partitions-query scanning all child tables
  • From: rverghese
• Re: Postgres partitions-query scanning all child tables
  • From: Corey Huinker
• performance issue with inherited foreign table
  • From: Dzmitry Nikitsin
• Postgres partitions-query scanning all child tables
  • From: rverghese
• Re: Primary key index partially used
  • From: Igor Neyman
• Re: Primary key index partially used
  • From: Igor Neyman
• Primary key index partially used
  • From: Florian Gossin
• Re: insert performance
  • From: Jim Nasby
• Re: High Planning Time
  • From: Tom Lane
• Re: High Planning Time
  • From: Vitalii Tymchyshyn
• Re: High Planning Time
  • From: Albe Laurenz
• Re: insert performance
  • From: Jinhua Luo
• High Planning Time
  • From: Phil S
• Re: insert performance
  • From: Jinhua Luo
• Re: Query order of magnitude slower with slightly different where clause
  • From: David Rowley
• Query order of magnitude slower with slightly different where clause
  • From: Adam Brusselback
• Re: insert performance
  • From: Jinhua Luo
• Re: insert performance
  • From: Jinhua Luo
• Re: Queries getting canceled inside a proc that seems to slow down randomly
  • From: Skarsol
• Re: Queries getting canceled inside a proc that seems to slow down randomly
  • From: Jim Nasby
• Re: Queries getting canceled inside a proc that seems to slow down randomly
  • From: Skarsol
• Re: insert performance
  • From: Jeff Janes
• Re: insert performance
  • From: Jim Nasby
• insert performance
  • From: Jinhua Luo
• Re: How we made Postgres upserts 2-3* quicker than MongoDB
  • From: Scott Marlowe
• Re: How we made Postgres upserts 2-3* quicker than MongoDB
  • From: Mark Zealey
• Re: How we made Postgres upserts 2-3* quicker than MongoDB
  • From: Nicolas Paris
• How we made Postgres upserts 2-3* quicker than MongoDB
  • From: Mark Zealey
• Re: Queries intermittently slow
  • From: Jim Nasby
• Re: Queries intermittently slow
  • From: Andres Freund
• Re: Slow query help
  • From: Almir de Oliveira Duarte Junior
• Re: Slow query help
  • From: Marc Mamin
• Re: Slow query help
  • From: Rafael Bernard Rodrigues Araujo
• Re: Queries intermittently slow
  • From: Tom Lane
• Re: Queries intermittently slow
  • From: Rick Otten
• Re: Queries intermittently slow
  • From: Scott Rankin
• Re: Queries intermittently slow
  • From: Scott Rankin
• Re: Queries intermittently slow
  • From: Tom Lane
• Re: Queries intermittently slow
  • From: Scott Rankin
• Slow query help
  • From: Almir de Oliveira Duarte Junior
• Re: Queries intermittently slow
  • From: Jim Nasby
• Re: Queries intermittently slow
  • From: Scott Rankin
• Re: Materialized view performance problems
  • From: Andreas Kretschmer
• Re: Queries intermittently slow
  • From: Tom Lane
• Re: Queries intermittently slow
  • From: Scott Rankin
• Re: Queries intermittently slow
  • From: Tom Lane
• Re: Queries intermittently slow
  • From: Scott Rankin
• Re: Queries intermittently slow
  • From: Tom Lane
• Re: Queries intermittently slow
  • From: Scott Rankin
• Re: Queries intermittently slow
  • From: Tom Lane
• Queries intermittently slow
  • From: Scott Rankin
• Re: Materialized view performance problems
  • From: Tom McLoughlin
• Re: Materialized view performance problems
  • From: Andreas Kretschmer
• Materialized view performance problems
  • From: Tom McLoughlin
• Re: Proposal for unlogged tables
  • From: Andres Freund
• Re: Proposal for unlogged tables
  • From: Mark Zealey
• Re: Proposal for unlogged tables
  • From: Andres Freund
• Re: Proposal for unlogged tables
  • From: Mark Zealey
• Re: Proposal for unlogged tables
  • From: Yves Dorfsman
• Re: Plan differences
  • From: Anton Melser
• Proposal for unlogged tables
  • From: Mark Zealey
• Re: Plan differences
  • From: Adam Pearson
• Re: Plan differences
  • From: Anton Melser
• Re: Plan differences
  • From: Anton Melser
• Re: Plan differences
  • From: Tom Lane
• Re: Plan differences
  • From: Jim Nasby
• Re: Plan differences
  • From: Tom Lane
• Re: Plan differences
  • From: Anton Melser
• Re: Plan differences
  • From: Pavel Stehule
• Plan differences
  • From: Anton Melser
• Re: [ADMIN] Connections "Startup"
  • From: Pavel Stehule
• Re: [ADMIN] Connections "Startup"
  • From: Om Prakash Jaiswal
• Re: [ADMIN] Connections "Startup"
  • From: Jim Nasby
• Re: Connections "Startup"
  • From: Rick Otten
• Re: Connections "Startup"
  • From: Pavel Stehule
• Connections "Startup"
  • From: Artem Tomyuk
• Re: Can't explain db size
  • From: Jim Nasby
• Re: Estimation row error
  • From: Pavel Stehule
• Re: Estimation row error
  • From: Mathieu VINCENT
• Re: Selectivity for lopsided foreign key columns
  • From: Mikkel Lauritsen
• Re: Terrible plan choice for view with distinct on clause
  • From: Adam Brusselback
• Re: Terrible plan choice for view with distinct on clause
  • From: Adam Brusselback
• Re: Can't explain db size
  • From: Matteo Grolla
• Re: Terrible plan choice for view with distinct on clause
  • From: Tom Lane
• Terrible plan choice for view with distinct on clause
  • From: Adam Brusselback
• Re: Selectivity for lopsided foreign key columns
  • From: Tom Lane
• Re: Can't explain db size
  • From: Matteo Grolla
• Re: Estimation row error
  • From: Mathieu VINCENT
• Re: Estimation row error
  • From: Mathieu VINCENT
• Selectivity for lopsided foreign key columns
  • From: Mikkel Lauritsen
• Re: Estimation row error
  • From: Matteo Grolla
• Re: Estimation row error
  • From: Mathieu VINCENT
• Re: Can't explain db size
  • From: Matteo Grolla
• Re: Estimation row error
  • From: Gunnar "Nick" Bluth
• Re: Can't explain db size
  • From: Andreas Kretschmer
• Can't explain db size
  • From: Matteo Grolla
• Re: Estimation row error
  • From: Andreas Kretschmer
• Re: Estimation row error
  • From: Gunnar "Nick" Bluth
• Re: Estimation row error
  • From: Mathieu VINCENT
• Re: Performance difference between Slon master and slave
  • From: Mattthew Lunnon
• Re: Getting an optimal plan on the first execution of a pl/pgsql function
  • From: Pedro França
• Re: Getting an optimal plan on the first execution of a pl/pgsql function
  • From: Tom Lane
• Re: Getting an optimal plan on the first execution of a pl/pgsql function
  • From: David G. Johnston
• Getting an optimal plan on the first execution of a pl/pgsql function
  • From: Pedro França
• Re: Performance difference between Slon master and slave
  • From: Jim Nasby
• Performance difference between Slon master and slave
  • From: Matthew Lunnon
• Re: Advise needed for a join query with a where conditional
  • From: Jeff Janes
• Re: partitioned table set and indexes
  • From: Andreas Kretschmer
• Re: partitioned table set and indexes
  • From: Rick Otten
• Re: partitioned table set and indexes
  • From: Andreas Kretschmer
• Re: Advise needed for a join query with a where conditional
  • From: Jim Nasby
• Re: checkpoints, proper config
  • From: Jim Nasby
• Re: checkpoints, proper config
  • From: Jim Nasby
• Re: partitioned table set and indexes
  • From: Rick Otten
• Re: partitioned table set and indexes
  • From: Andreas Kretschmer
• Re: partitioned table set and indexes
  • From: Kevin Grittner
• Re: partitioned table set and indexes
  • From: Rick Otten
• Re: partitioned table set and indexes
  • From: Andreas Kretschmer
• partitioned table set and indexes
  • From: Rick Otten
• Re: Estimation row error
  • From: Mathieu VINCENT
• Estimation row error
  • From: Mathieu VINCENT
• Re: Advise needed for a join query with a where conditional
  • From: ankur_adwyze
• Advise needed for a join query with a where conditional
  • From: ankur_adwyze
• Re: checkpoints, proper config
  • From: Tomas Vondra
• Re: checkpoints, proper config
  • From: Alvaro Herrera
• Re: checkpoints, proper config
  • From: Tomas Vondra
• Re: checkpoints, proper config
  • From: Joshua D. Drake
• Re: checkpoints, proper config
  • From: Tory M Blue
• postgresql upgrade from 9.3 to 9.4 error
  • From: Sheena, Prabhjot
• Re: checkpoints, proper config
  • From: Joshua D. Drake
• Re: checkpoints, proper config
  • From: Tory M Blue
• Re: checkpoints, proper config
  • From: Joshua D. Drake
• checkpoints, proper config
  • From: Tory M Blue
• Re: Slow Index Creation, why is it not consuming more memory.
  • From: Peter Geoghegan
• Slow Index Creation, why is it not consuming more memory.
  • From: Tory M Blue
• ossp-uuid: Performance considerations for different UUID approaches?
  • From: Brendan McCollam
• Re: Index scan cost calculation
  • From: Glyn Astill
• Re: Index scan cost calculation
  • From: Jim Nasby
• Re: Index scan cost calculation
  • From: Glyn Astill
• Re: Index scan cost calculation
  • From: Jeff Janes
• Re: Index scan cost calculation
  • From: Glyn Astill
• Re: Query that took a lot of time in Postgresql when not using trim in order by
  • From: Tom Lane
• Re: Query that took a lot of time in Postgresql when not using trim in order by
  • From: Peter J. Holzer
• Re: Index scan cost calculation
  • From: Jeff Janes
• Re: Index scan cost calculation
  • From: Tom Lane
• Re: Index scan cost calculation
  • From: Glyn Astill
• Re: Index scan cost calculation
  • From: Tom Lane
• Re: Index scan cost calculation
  • From: Glyn Astill
• Index scan cost calculation
  • From: Glyn Astill
• Re: No index only scan on md5 index
  • From: Albe Laurenz
• Re: No index only scan on md5 index
  • From: Adam Brusselback
• Re: No index only scan on md5 index
  • From: Adam Brusselback