Postgres Performance Date Index

• Thread Index

• Re: Why shared_buffers max is 8GB?
  • From: Markella Skempri
• Re: Why shared_buffers max is 8GB?
  • From: Albe Laurenz
• Re: Why shared_buffers max is 8GB?
  • From: desmodemone
• Re: Why shared_buffers max is 8GB?
  • From: Ilya Kosmodemiansky
• Why shared_buffers max is 8GB?
  • From: Alexey Vasiliev
• Re: Stalls on PGSemaphoreLock
  • From: Takashi Horikawa
• Re: Stalls on PGSemaphoreLock
  • From: Emre Hasegeli
• Re: Stalls on PGSemaphoreLock
  • From: Matthew Spilich
• Re: Stalls on PGSemaphoreLock
  • From: Ray Stell
• Re: pg_dump vs pg_basebackup
  • From: Claudio Freire
• Re: pg_dump vs pg_basebackup
  • From: Alan Hodgson
• Re: pg_dump vs pg_basebackup
  • From: Joshua D. Drake
• Re: pg_dump vs pg_basebackup
  • From: Graeme B. Bell
• Re: pg_dump vs pg_basebackup
  • From: Ilya Kosmodemiansky
• Re: pg_dump vs pg_basebackup
  • From: Magnus Hagander
• Re: pg_dump vs pg_basebackup
  • From: Ilya Kosmodemiansky
• Re: pg_dump vs pg_basebackup
  • From: Ilya Kosmodemiansky
• Re: pg_dump vs pg_basebackup
  • From: Joshua D. Drake
• Re: pg_dump vs pg_basebackup
  • From: Magnus Hagander
• Re: pg_dump vs pg_basebackup
  • From: Ilya Kosmodemiansky
• Re: pg_dump vs pg_basebackup
  • From: desmodemone
• Re: pg_dump vs pg_basebackup
  • From: Joshua D. Drake
• Stalls on PGSemaphoreLock
  • From: Matthew Spilich
• Re: pg_dump vs pg_basebackup
  • From: Claudio Freire
• Re: pg_dump vs pg_basebackup
  • From: David Johnston
• Re: pg_dump vs pg_basebackup
  • From: Ilya Kosmodemiansky
• Re: pg_dump vs pg_basebackup
  • From: gianfranco caca
• Re: pg_dump vs pg_basebackup
  • From: Ilya Kosmodemiansky
• Re: slow join not using index properly
  • From: Ilya Kosmodemiansky
• pg_dump vs pg_basebackup
  • From: gianfranco caca
• Re: Connection pooling - Number of connections
  • From: Brett Wooldridge
• Re: Connection pooling - Number of connections
  • From: Gavin Flower
• Re: Connection pooling - Number of connections
  • From: Brett Wooldridge
• Re: Connection pooling - Number of connections
  • From: Gavin Flower
• Re: slow join not using index properly
  • From: Stefan Amshey
• Re: Suboptimal query plan when using expensive BCRYPT functions
  • From: Erik van Zijst
• Connection pooling - Number of connections
  • From: Brett Wooldridge
• Re: Suboptimal query plan when using expensive BCRYPT functions
  • From: Heikki Linnakangas
• Re: Suboptimal query plan when using expensive BCRYPT functions
  • From: Erik van Zijst
• Re: Suboptimal query plan when using expensive BCRYPT functions
  • From: Tom Lane
• Re: Query taking long time
  • From: Venkata Balaji Nagothi
• Re: Suboptimal query plan when using expensive BCRYPT functions
  • From: bricklen
• Re: Suboptimal query plan when using expensive BCRYPT functions
  • From: Erik van Zijst
• Re: Suboptimal query plan when using expensive BCRYPT functions
  • From: bricklen
• Re: Suboptimal query plan when using expensive BCRYPT functions
  • From: Erik van Zijst
• Re: Suboptimal query plan when using expensive BCRYPT functions
  • From: bricklen
• Suboptimal query plan when using expensive BCRYPT functions
  • From: Erik van Zijst
• Re: Getting query plan alternatives from query planner?
  • From: Shaun Thomas
• Re: Connection pooling - Number of connections
  • From: Claudio Freire
• Re: Connection pooling - Number of connections
  • From: David Johnston
• Re: Connection pooling - Number of connections
  • From: Guillaume Smet
• Re: Connection pooling - Number of connections
  • From: Guillaume Smet
• Re: Connection pooling - Number of connections
  • From: Sethu Prasad
• Re: Connection pooling - Number of connections
  • From: Tom Lane
• Re: Connection pooling - Number of connections
  • From: Guillaume Smet
• Re: Connection pooling - Number of connections
  • From: David Johnston
• Connection pooling - Number of connections
  • From: Guillaume Smet
• Re: Getting query plan alternatives from query planner?
  • From: Tom Lane
• Re: Getting query plan alternatives from query planner?
  • From: Craig James
• Re: slow join not using index properly
  • From: Vincent
• Re: Getting query plan alternatives from query planner?
  • From: Atri Sharma
• Re: Getting query plan alternatives from query planner?
  • From: Stefan Keller
• Re: slow join not using index properly
  • From: Ilya Kosmodemiansky
• Re: Performance of UNION vs IN
  • From: Jean-Max Reymond
• slow join not using index properly
  • From: Stefan Amshey
• Re: Performance of UNION vs IN
  • From: Torsten Förtsch
• Re: Getting query plan alternatives from query planner?
  • From: Tom Lane
• Performance of UNION vs IN
  • From: Jean-Max Reymond
• Getting query plan alternatives from query planner?
  • From: Stefan Keller
• Re: long lasting select, no io nor cpu usage ?
  • From: Franck Routier
• Re: long lasting select, no io nor cpu usage ?
  • From: Tom Lane
• Re: long lasting select, no io nor cpu usage ?
  • From: Franck Routier
• Re: long lasting select, no io nor cpu usage ?
  • From: Tom Lane
• long lasting select, no io nor cpu usage ?
  • From: Franck Routier
• Re: Query taking long time
  • From: acanada
• Re: Query taking long time
  • From: Venkata Balaji Nagothi
• Re: slave wal is ahead of master
  • From: Evgeny Shishkin
• Re: slave wal is ahead of master
  • From: Sethu Prasad
• slave wal is ahead of master
  • From: Evgeniy Shishkin
• Re: Query taking long time
  • From: acanada
• Re: question about partial index
  • From: Szymon Guz
• question about partial index
  • From: Yu Zhao
• Re: Help me understand why my subselect is an order of magnitude faster than my nested joins
  • From: Vincent
• Re: Adding new field to big table
  • From: Jeff Janes
• Re: Adding new field to big table
  • From: acanada
• Re: Adding new field to big table
  • From: Jeff Janes
• Re: Adding new field to big table
  • From: acanada
• Re: Adding new field to big table
  • From: Jeff Janes
• Adding new field to big table
  • From: acanada
• Re: Very slow query in PostgreSQL 9.3.3
  • From: Ian Lawrence Barwick
• Re: [BUGS] Very slow query in PostgreSQL 9.3.3
  • From: Sergey Konoplev
• Re: [BUGS] Very slow query in PostgreSQL 9.3.3
  • From: Pavel Stehule
• Very slow query in PostgreSQL 9.3.3
  • From: fburgess
• Re: Query taking long time
  • From: Evgeny Shishkin
• Re: Ye olde slow query
  • From: Tom Lane
• Ye olde slow query
  • From: Murphy, Kevin
• Re: Query taking long time
  • From: acanada
• Re: Query taking long time
  • From: desmodemone
• Re: Query taking long time
  • From: Venkata Balaji Nagothi
• Re: Query taking long time
  • From: acanada
• Re: Query taking long time
  • From: Evgeniy Shishkin
• Re: How can I get the query planner to use a bitmap index scap instead of an index scan ?
  • From: Mohan Krishnan
• Re: How can I get the query planner to use a bitmap index scap instead of an index scan ?
  • From: Jeff Janes
• How can I get the query planner to use a bitmap index scap instead of an index scan ?
  • From: Mohan Krishnan
• Re: Query taking long time
  • From: acanada
• Re: Query taking long time
  • From: Evgeniy Shishkin
• Re: Query taking long time
  • From: acanada
• Re: Query taking long time
  • From: Evgeniy Shishkin
• Re: Slow query
  • From: David Johnston
• Re: Slow query
  • From: Bikram Kesari Naik
• Re: Slow query
  • From: David Johnston
• Slow query
  • From: Bikram Kesari Naik
• Re: Query taking long time
  • From: acanada
• Re: Query taking long time
  • From: desmodemone
• Re: Query taking long time
  • From: acanada
• Help me understand why my subselect is an order of magnitude faster than my nested joins
  • From: Eli Naeher
• Re: Optimal settings for RAID controller - optimized for writes
  • From: Merlin Moncure
• Re: Query taking long time
  • From: Venkata Balaji Nagothi
• Re: Help with optimizing a query over hierarchical data
  • From: Damon Snyder
• Re: Query taking long time
  • From: acanada
• Re: Query taking long time
  • From: acanada
• Re: Help with optimizing a query over hierarchical data
  • From: Claudio Freire
• Re: Help with optimizing a query over hierarchical data
  • From: Damon Snyder
• Re: Query taking long time
  • From: Venkata Balaji Nagothi
• Re: Help with optimizing a query over hierarchical data
  • From: Claudio Freire
• Subselect an order of magnitude faster than nested joins
  • From: Eli Naeher
• Re: Help with optimizing a query over hierarchical data
  • From: Damon Snyder
• Re: Query taking long time
  • From: Vladimir Sitnikov
• Re: Query taking long time
  • From: acanada
• Re: Help with optimizing a query over hierarchical data
  • From: Claudio Freire
• Help with optimizing a query over hierarchical data
  • From: Damon Snyder
• Re: Inefficient filter order in query plan
  • From: Tom Coogan
• Re: Inefficient filter order in query plan
  • From: Tom Lane
• Re: Inefficient filter order in query plan
  • From: Tom Coogan
• Re: Inefficient filter order in query plan
  • From: Tom Lane
• Re: Inefficient filter order in query plan
  • From: Stephen Frost
• Re: Inefficient filter order in query plan
  • From: Tom Lane
• Inefficient filter order in query plan
  • From: Tom Coogan
• Re: not using my GIN index in JOIN expression
  • From: Jean-Max Reymond
• Re: not using my GIN index in JOIN expression
  • From: Heikki Linnakangas
• not using my GIN index in JOIN expression
  • From: Jean-Max Reymond
• Re: Query taking long time
  • From: acanada
• Re: Postgresql tunning-- help needed
  • From: Tomas Vondra
• Query taking long time
  • From: acanada
• 9.2.4 specified item offset is too large, now what?
  • From: Tory M Blue
• Re: Problem with ExclusiveLock on inserts
  • From: Бородин Владимир
• Re: Planner performance extremely affected by an hanging transaction (20-30 times)?
  • From: Josh Berkus
• Re: Planner performance extremely affected by an hanging transaction (20-30 times)?
  • From: Tom Lane
• Re: Bloated tables and why is vacuum full the only option
  • From: Claudio Freire
• Re: 9.1.2 Postgres corruption, any way to recover?
  • From: Tomas Vondra
• 9.1.2 Postgres corruption, any way to recover?
  • From: Tory M Blue
• Re: Lack of index usage when doing array casts
  • From: Peter Geoghegan
• Re: Lack of index usage when doing array casts
  • From: Alexey Klyukin
• Re: Lack of index usage when doing array casts
  • From: Tom Lane
• Re: Lack of index usage when doing array casts
  • From: Tom Lane
• Lack of index usage when doing array casts
  • From: Alexey Klyukin
• Postgresql tunning-- help needed
  • From: Ashutosh Durugkar
• Re: Optimal settings for RAID controller - optimized for writes
  • From: Tomas Vondra
• Re: Optimal settings for RAID controller - optimized for writes
  • From: KONDO Mitsumasa
• Optimal settings for RAID controller - optimized for writes
  • From: Niels Kristian Schjødt
• Re: Problem with ExclusiveLock on inserts
  • From: Ilya Kosmodemiansky
• Re: Optimal settings for RAID controller - optimized for writes
  • From: Scott Marlowe
• Re: Optimal settings for RAID controller - optimized for writes
  • From: Tomas Vondra
• Re: Optimal settings for RAID controller - optimized for writes
  • From: Tomas Vondra
• Re: Optimal settings for RAID controller - optimized for writes
  • From: Merlin Moncure
• Re: Optimal settings for RAID controller - optimized for writes
  • From: Tomas Vondra
• Re: Optimal settings for RAID controller - optimized for writes
  • From: Scott Marlowe
• Re: Optimal settings for RAID controller - optimized for writes
  • From: Merlin Moncure
• Re: Optimal settings for RAID controller - optimized for writes
  • From: KONDO Mitsumasa
• Re: Optimal settings for RAID controller - optimized for writes
  • From: Tomas Vondra
• Re: DB size and TABLE sizes don't seem to add up
  • From: David Wall
• Re: Optimal settings for RAID controller - optimized for writes
  • From: Michael Stone
• Re: DB size and TABLE sizes don't seem to add up
  • From: Heikki Linnakangas
• Re: Optimal settings for RAID controller - optimized for writes
  • From: Scott Marlowe
• Re: Why is the optimiser choosing the slower query, or, understanding explain analyze output
  • From: Tom Lane
• Re: Why is the optimiser choosing the slower query, or, understanding explain analyze output
  • From: Alistair Bayley
• Re: Why is the optimiser choosing the slower query, or, understanding explain analyze output
  • From: Tom Lane
• Re: Optimal settings for RAID controller - optimized for writes
  • From: KONDO Mitsumasa
• Re: Why is the optimiser choosing the slower query, or, understanding explain analyze output
  • From: Jeff Janes
• DB size and TABLE sizes don't seem to add up
  • From: David Wall
• Why is the optimiser choosing the slower query, or, understanding explain analyze output
  • From: Alistair Bayley
• Re: Optimal settings for RAID controller - optimized for writes
  • From: Tomas Vondra
• Re: Optimal settings for RAID controller - optimized for writes
  • From: Tomas Vondra
• Re: Optimal settings for RAID controller - optimized for writes
  • From: DFE
• Optimal settings for RAID controller - optimized for writes
  • From: Niels Kristian Schjødt
• Re: Can one Dump schema without index/constraints?
  • From: Tory M Blue
• Re: Can one Dump schema without index/constraints?
  • From: Michael Paquier
• Can one Dump schema without index/constraints?
  • From: Tory M Blue
• Re: Problem with ExclusiveLock on inserts
  • From: Ilya Kosmodemiansky
• Re: Problem with ExclusiveLock on inserts
  • From: Бородин Владимир
• Re: Problem with ExclusiveLock on inserts
  • From: Emre Hasegeli
• Re: Problem with ExclusiveLock on inserts
  • From: Ilya Kosmodemiansky
• Re: Problem with ExclusiveLock on inserts
  • From: Бородин Владимир
• Re: Problem with ExclusiveLock on inserts
  • From: Emre Hasegeli
• Re: Problem with ExclusiveLock on inserts
  • From: Бородин Владимир
• Re: Problem with ExclusiveLock on inserts
  • From: Ilya Kosmodemiansky
• Re: Problem with ExclusiveLock on inserts
  • From: Бородин Владимир
• Re: Problem with ExclusiveLock on inserts
  • From: Ilya Kosmodemiansky
• Re: Problem with ExclusiveLock on inserts
  • From: Бородин Владимир
• Re: Problem with ExclusiveLock on inserts
  • From: Ilya Kosmodemiansky
• Re: Problem with ExclusiveLock on inserts
  • From: Бородин Владимир
• Re: Problem with ExclusiveLock on inserts
  • From: Ilya Kosmodemiansky
• Problem with ExclusiveLock on inserts
  • From: Бородин Владимир
• Re: list number of entries to be delete in cascading deletes
  • From: Eildert Groeneveld
• Re: increasing query time after analyze
  • From: Pavel Stehule
• increasing query time after analyze
  • From: Katharina Koobs
• Re: Postgres Query Plan Live Lock
  • From: Jeff Janes
• Re: Bloated tables and why is vacuum full the only option
  • From: Claudio Freire
• Re: Bloated tables and why is vacuum full the only option
  • From: Jeff Janes
• Re: list number of entries to be delete in cascading deletes
  • From: Claudio Freire
• list number of entries to be delete in cascading deletes
  • From: Eildert Groeneveld
• Re: Strange performance boost with random()
  • From: Tom Lane
• Re: Strange performance boost with random()
  • From: Sébastien Lorion
• Re: Strange performance boost with random()
  • From: Heikki Linnakangas
• Strange performance boost with random()
  • From: M Putz
• Re: Bloated tables and why is vacuum full the only option
  • From: Sergey Konoplev
• Re: Bloated tables and why is vacuum full the only option
  • From: Claudio Freire
• Re: Bloated tables and why is vacuum full the only option
  • From: Sergey Konoplev
• Re: Bloated tables and why is vacuum full the only option
  • From: Claudio Freire
• Re: Bloated tables and why is vacuum full the only option
  • From: Tom Lane
• Re: Bloated tables and why is vacuum full the only option
  • From: Claudio Freire
• Re: Bloated tables and why is vacuum full the only option
  • From: Tomas Vondra
• Re: Performance Benchmarking for data-warehousing instance?
  • From: Tomas Vondra
• Re: Performance Benchmarking for data-warehousing instance?
  • From: Wattana Hinchaisri
• Re: Performance Benchmarking for data-warehousing instance?
  • From: Huy Nguyen
• Re: Performance Benchmarking for data-warehousing instance?
  • From: Peter Geoghegan
• Performance Benchmarking for data-warehousing instance?
  • From: Huy Nguyen
• Bloated tables and why is vacuum full the only option
  • From: Claudio Freire
• Re: Postgres Query Plan Live Lock
  • From: Claudio Freire
• Re: Postgres Query Plan Live Lock
  • From: Pweaver (Paul Weaver)
• Re: Postgres Query Plan Live Lock
  • From: Pweaver (Paul Weaver)
• Re: Postgres Query Plan Live Lock
  • From: bricklen
• Re: increasing query time after analyze
  • From: Claudio Freire
• Postgres Query Plan Live Lock
  • From: Jeff Janes
• Re: increasing query time after analyze
  • From: Pavel Stehule
• increasing query time after analyze
  • From: Katharina Koobs
• Re: Postgres Query Plan Live Lock
  • From: Peter Geoghegan
• Re: Re: Increased memory utilization by pgsql backend after upgrade from 9.1.3 to 9.2.6
  • From: Claudio Freire
• Re: Increased memory utilization by pgsql backend after upgrade from 9.1.3 to 9.2.6
  • From: Dattaram Porob
• Postgres Query Plan Live Lock
  • From: Pweaver (Paul Weaver)
• Planner estimates and VACUUM/autovacuum
  • From: Artur Zając CFI
• Re: Planner estimates and VACUUM/autovacuum
  • From: Tom Lane
• Planner estimates and VACUUM/autovacuum
  • From: Artur Zając
• Re: PostgreSQL 9.3.2 Performance tuning for 32 GB server
  • From: Tom Kincaid
• Re: PostgreSQL 9.3.2 Performance tuning for 32 GB server
  • From: Julien Cigar
• Re: trick the query optimiser to skip some optimisations
  • From: Jeff Janes
• Re: trick the query optimiser to skip some optimisations
  • From: Sergey Konoplev
• Re: WHERE with ORDER not using the best index
  • From: Tom Lane
• Increased memory utilization by pgsql backend after upgrade from 9.1.3 to 9.2.6
  • From: Dattaram Porob
• Slow query on join with Date >=
  • From: Jim Treinen
• PostgreSQL 9.3.2 Performance tuning for 32 GB server
  • From: RAMAKRISHNAN KANDASAMY
• Re: WHERE with ORDER not using the best index
  • From: jugnooken
• Re: trick the query optimiser to skip some optimisations
  • From: Дмитрий Шалашов
• Re: trick the query optimiser to skip some optimisations
  • From: Jeff Janes
• trick the query optimiser to skip some optimisations
  • From: Дмитрий Шалашов
• Re: WHERE with ORDER not using the best index
  • From: Tom Lane
• Re: Select hangs and there are lots of files in table and index directories.
  • From: Tom Lane
• WHERE with ORDER not using the best index
  • From: jugnooken
• Re: Select hangs and there are lots of files in table and index directories.
  • From: Peter Blair
• Re: Select hangs and there are lots of files in table and index directories.
  • From: Peter Blair
• Re: Slow query (wrong index used maybe)
  • From: bobJobS
• Re: Slow query (wrong index used maybe)
  • From: Stelian Iancu
• Re: Select hangs and there are lots of files in table and index directories.
  • From: Tom Lane
• Fwd: Increased memory utilization by pgsql backend after upgrade from 9.1.3 to 9.2.6
  • From: Dattaram Porob
• Select hangs and there are lots of files in table and index directories.
  • From: Peter Blair
• Re: Slow query (wrong index used maybe)
  • From: Gavin Flower
• Re: Slow query (wrong index used maybe)
  • From: bobJobS
• Re: Slow query (wrong index used maybe)
  • From: Stelian Iancu
• Re: Slow query (wrong index used maybe)
  • From: Stelian Iancu
• Re: Slow query (wrong index used maybe)
  • From: salah jubeh
• Re: Slow query (wrong index used maybe)
  • From: Tom Lane
• Slow query (wrong index used maybe)
  • From: Stelian Iancu
• Re: pg_repack solves alter table set tablespace lock
  • From: Alvaro Herrera
• Re: pg_repack solves alter table set tablespace lock
  • From: Ying He
• self join, parameterized base/join rel path row estimation and generally...
  • From: Bongseo Jang
• Re: pg_repack solves alter table set tablespace lock
  • From: Josh Kupershmidt
• pg_repack solves alter table set tablespace lock
  • From: Ying He
• Re: PostgreSQL 9.3.2 Performance issues
  • From: Kevin Grittner
• PostgreSQL 9.3.2 Performance issues
  • From: fburgess
• Removing nulls with 6NF
  • From: Robert DiFalco
• Re: Time of query result delivery
  • From: Josh Berkus
• Re: Time of query result delivery
  • From: Josh Berkus
• Re: Increasing query time after updates
  • From: Mark Kirkwood
• Re: Increasing query time after updates
  • From: Tomas Vondra
• Re: Increasing query time after updates
  • From: Mark Kirkwood
• Re: Increasing query time after updates
  • From: Katharina Koobs
• Re: Increasing query time after updates
  • From: Heikki Linnakangas
• Increasing query time after updates
  • From: Katharina Koobs
• Time of query result delivery
  • From: ARCEnergo
• Re: Wrong index selection
  • From: Tom Lane
• Wrong index selection
  • From: Piotr Gasidło
• Re: Issue with query scanning through all data even with indexes
  • From: Igor Neyman
• Re: Slow counting on v9.3
  • From: Guillaume Cottenceau
• Re: Slow counting on v9.3
  • From: Mehmet Çakoğlu
• Slow counting on v9.3
  • From: Kai Sellgren
• Issue with query scanning through all data even with indexes
  • From: Kai Sellgren
• PostgreSQL query for cache performance counters?
  • From: ambilalmca
• Re: COMMIT stuck for days after bulk delete
  • From: Josh Kupershmidt
• Re: COMMIT stuck for days after bulk delete
  • From: Tom Lane
• COMMIT stuck for days after bulk delete
  • From: Josh Kupershmidt
• Re: query plan not optimal
  • From: Marc Cousin
• Wrong rows count estimation in query with simple UNION ALL leads to drammatically slow plan
  • From: Michael Kolomeitsev
• Re: window function induces full table scan
  • From: Thomas Mayer
• Re: window function induces full table scan
  • From: Tom Lane
• Re: window function induces full table scan
  • From: Thomas Mayer
• Re: window function induces full table scan
  • From: Tom Lane
• Re: window function induces full table scan
  • From: Thomas Mayer
• Re: window function induces full table scan
  • From: Thomas Mayer
• Re: window function induces full table scan
  • From: Tom Lane
• Re: window function induces full table scan
  • From: Thomas Mayer
• Re: window function induces full table scan
  • From: Thomas Mayer
• Re: window function induces full table scan
  • From: Tom Lane
• Re: window function induces full table scan
  • From: Jeff Janes
• Re: window function induces full table scan
  • From: Tom Lane
• window function induces full table scan
  • From: Thomas Mayer
• Re: DATE_TRUNC() and GROUP BY?
  • From: Dave Johansen
• Re: DATE_TRUNC() and GROUP BY?
  • From: Dave Johansen
• Re: DATE_TRUNC() and GROUP BY?
  • From: Dave Johansen
• Re: Performance bug in prepared statement binding in 9.2?
  • From: Tom Lane
• Re: Recommendations for partitioning?
  • From: Alvaro Herrera
• Re: Recommendations for partitioning?
  • From: Sergey Konoplev
• Re: Possible regression (slow query on 9.2/9.3 when compared to 9.1)
  • From: Tom Lane
• Re: Error install -pgmemcache
  • From: Devrim GÜNDÜZ
• query plan not optimal
  • From: Jeff Janes
• Re: Pg makes nonoptimal choice between two multicolumn indexes with the same columns but in different order.
  • From: Michael Kolomeitsev
• Re: Pg makes nonoptimal choice between two multicolumn indexes with the same columns but in different order.
  • From: Tom Lane
• Re: Pg makes nonoptimal choice between two multicolumn indexes with the same columns but in different order.
  • From: Gavin Flower
• Re: Pg makes nonoptimal choice between two multicolumn indexes with the same columns but in different order.
  • From: Kevin Grittner
• Re: Are there some additional postgres tuning to improve performance in multi tenant system
  • From: Andrew Dunstan
• Re: Are there some additional postgres tuning to improve performance in multi tenant system
  • From: ankush upadhyay
• Re: Are there some additional postgres tuning to improve performance in multi tenant system
  • From: Andrew Dunstan
• Re: Are there some additional postgres tuning to improve performance in multi tenant system
  • From: ankush upadhyay
• Re: Are there some additional postgres tuning to improve performance in multi tenant system
  • From: Mark Kirkwood
• Are there some additional postgres tuning to improve performance in multi tenant system
  • From: ankush upadhyay
• Re: query not using index
  • From: Mark Kirkwood
• Re: Does fsync on/off for wal AND Checkpoint?
  • From: Andreas Karlsson
• Does fsync on/off for wal AND Checkpoint?
  • From: GR Vishwanath
• Pg makes nonoptimal choice between two multicolumn indexes with the same columns but in different order.
  • From: Michael Kolomeitsev
• Possible regression (slow query on 9.2/9.3 when compared to 9.1)
  • From: Ronaldo Maia
• Re: How to completely delete iPhone all data before selling?
  • From: shirleymi
• Re: Bytea(TOAST) vs large object facility(OID)
  • From: Albe Laurenz
• Re: Optimizing a query
  • From: Mark Kirkwood
• Bytea(TOAST) vs large object facility(OID)
  • From: kosalram Babu Chellappa
• Re: slow query - will CLUSTER help?
  • From: Shaun Thomas
• Re: query not using index
  • From: Johann Spies
• Strange number of rows in plan cost
  • From: Алексей Кузнецов
• Re: DATE_TRUNC() and GROUP BY?
  • From: David Rowley
• Re: slow query - will CLUSTER help?
  • From: Gavin Flower
• Re: Recommendations for partitioning?
  • From: Dave Johansen
• Re: Recommendations for partitioning?
  • From: Dave Johansen
• Re: Recommendations for partitioning?
  • From: Shaun Thomas
• Re: Recommendations for partitioning?
  • From: Alvaro Herrera
• Re: slow query - will CLUSTER help?
  • From: Shaun Thomas
• Re: Recommendations for partitioning?
  • From: bricklen
• Re: Recommendations for partitioning?
  • From: Dave Johansen
• Re: Unexpected pgbench result
  • From: Dave Johansen
• Re: Unexpected pgbench result
  • From: Kevin Grittner
• Re: Unexpected pgbench result
  • From: Dave Johansen
• Re: slow query - will CLUSTER help?
  • From: Shaun Thomas
• Re: Regarding Hardware Tuning
  • From: Shaun Thomas
• Re: Unexpected pgbench result
  • From: Shaun Thomas
• Re: query plan not optimal
  • From: Marc Cousin
• Re: Regarding Hardware Tuning
  • From: Scott Marlowe
• DATE_TRUNC() and GROUP BY?
  • From: Dave Johansen
• Re: Regarding Hardware Tuning
  • From: Steve Crawford
• Re: Unexpected pgbench result
  • From: Dave Johansen
• Re: slow query - will CLUSTER help?
  • From: Sergey Konoplev
• Re: query plan not optimal
  • From: Kevin Grittner
• Re: slow query - will CLUSTER help?
  • From: Sergey Konoplev
• Re: slow query - will CLUSTER help?
  • From: Jeff Janes
• Re: slow query - will CLUSTER help?
  • From: Kevin Grittner
• Re: query plan not optimal
  • From: Marc Cousin
• Re: query plan not optimal
  • From: Jeff Janes
• Re: slow query - will CLUSTER help?
  • From: Shaun Thomas
• Re: Optimizing a query
  • From: Shaun Thomas
• Re: Unexpected pgbench result
  • From: Shaun Thomas
• Re: Re: Problem with slow query with WHERE conditions with OR clause on primary keys
  • From: Pavel Stehule
• Re: Recommendations for partitioning?
  • From: Scott Marlowe
• Unexpected pgbench result
  • From: Dave Johansen
• Re: Recommendations for partitioning?
  • From: Dave Johansen
• Regarding Hardware Tuning
  • From: prashant Pandey
• Re: Problem with slow query with WHERE conditions with OR clause on primary keys
  • From: kolszew73@xxxxxxxxx
• Optimizing a query
  • From: Kai Sellgren
• Help with cursor query that is intermittently slow
  • From: Drew Jetter
• slow loading of pages for SELECT query - will CLUSTER help?
  • From: Sev Zaslavsky
• slow query - will CLUSTER help?
  • From: Sev Zaslavsky
• Re: Debugging shared memory issues on CentOS
  • From: Mack Talcott
• query plan not optimal
  • From: Marc Cousin
• Re: query not using index
  • From: Tom Lane
• query not using index
  • From: Johann Spies
• Re: Problem with slow query with WHERE conditions with OR clause on primary keys
  • From: Andreas Karlsson
• Re: Problem with slow query with WHERE conditions with OR clause on primary keys
  • From: David Johnston
• Re: Current query of the PL/pgsql procedure.
  • From: Guillaume Lelarge
• Re: Adding an additional join causes very different/slow query plan
  • From: Stephen Frost
• Re: Adding an additional join causes very different/slow query plan
  • From: Joe Van Dyk
• Re: Adding an additional join causes very different/slow query plan
  • From: Tom Lane
• Re: Adding an additional join causes very different/slow query plan
  • From: Joe Van Dyk
• Adding an additional join causes very different/slow query plan
  • From: Joe Van Dyk
• Re: Current query of the PL/pgsql procedure.
  • From: Andrew Dunstan
• Re: Current query of the PL/pgsql procedure.
  • From: Matheus de Oliveira
• Re: Current query of the PL/pgsql procedure.
  • From: Yuri Levinsky
• Re: Current query of the PL/pgsql procedure.
  • From: hubert depesz lubaczewski
• Re: Current query of the PL/pgsql procedure.
  • From: Craig James
• Current query of the PL/pgsql procedure.
  • From: Yuri Levinsky
• Re: Slow query due to slow I/O
  • From: Bryce Covert
• Re: Slow query due to slow I/O
  • From: Jeff Janes
• Re: Slow query due to slow I/O
  • From: Claudio Freire
• Re: Slow query due to slow I/O
  • From: Bryce Covert
• Re: Slow query due to slow I/O
  • From: Bryce Covert
• Re: Slow query due to slow I/O
  • From: Claudio Freire
• Re: Slow query due to slow I/O
  • From: Bryce Covert
• Re: Slow query due to slow I/O
  • From: Bryce Covert
• Re: Slow query due to slow I/O
  • From: Claudio Freire
• Re: Slow query due to slow I/O
  • From: Bryce Covert
• Re: Slow query due to slow I/O
  • From: Claudio Freire
• Slow query due to slow I/O
  • From: Bryce Covert
• Re: Debugging shared memory issues on CentOS
  • From: Tom Lane
• Re: Debugging shared memory issues on CentOS
  • From: Merlin Moncure
• Re: ORDER BY using index, tsearch2
  • From: Janek Sendrowski
• Re: ORDER BY using index, tsearch2
  • From: Tom Lane
• Re: Debugging shared memory issues on CentOS
  • From: Tom Lane
• Re: select count(distinct ...) is slower than select distinct in about 5x
  • From: jacket41142
• Re: Debugging shared memory issues on CentOS
  • From: Mack Talcott
• Re: ORDER BY using index, tsearch2
  • From: Janek Sendrowski
• Re: ORDER BY using index, tsearch2
  • From: Tom Lane
• Re: ORDER BY using index, tsearch2
  • From: Craig James
• Re: ORDER BY using index, tsearch2 [READ THIS!]
  • From: Tom Lane
• ORDER BY using index, tsearch2 [READ THIS!]
  • From: Janek Sendrowski
• ORDER BY using index, tsearch2
  • From: Janek Sendrowski
• When is a query slow?
  • From: Michael Sacket
• Re: Problem with slow query with WHERE conditions with OR clause on primary keys
  • From: David Johnston
• Re: Debugging shared memory issues on CentOS
  • From: Tom Lane
• select count(distinct ...) is slower than select distinct in about 5x
  • From: jacket41142
• Problem with slow query with WHERE conditions with OR clause on primary keys
  • From: Krzysztof Olszewski
• Debugging shared memory issues on CentOS
  • From: Mack Talcott
• Re: select count(distinct ...) is slower than select distinct in about 5x
  • From: Jeff Janes
• Re: select count(distinct ...) is slower than select distinct in about 5x
  • From: jacket41142
• Re: select count(distinct ...) is slower than select distinct in about 5x
  • From: jacket41142
• Re: Explain analyze time overhead
  • From: Bruce Momjian
• Re: Explain analyze time overhead
  • From: salah jubeh
• Re: Explain analyze time overhead
  • From: Bruce Momjian
• Re: Parallel Select query performance and shared buffers
  • From: Merlin Moncure
• Re: Parallel Select query performance and shared buffers
  • From: Claudio Freire
• Re: Parallel Select query performance and shared buffers
  • From: Merlin Moncure
• Re: select count(distinct ...) is slower than select distinct in about 5x
  • From: Jeff Janes
• Re: select count(distinct ...) is slower than select distinct in about 5x
  • From: Kevin Grittner
• select count(distinct ...) is slower than select distinct in about 5x
  • From: jacket41142
• Hash join
  • From: mspasic
• Re: Recommendations for partitioning?
  • From: Scott Marlowe
• Re: Recommendations for partitioning?
  • From: Jeff Janes
• Re: Recommendations for partitioning?
  • From: desmodemone
• Re: postgres performance
  • From: desmodemone
• Re: One huge db vs many small dbs
  • From: Oliver Seemann
• Re: postgres performance
  • From: chidamparam muthusamy
• Re: postgres performance
  • From: Tomas Vondra
• Re: WAL + SSD = slow inserts?
  • From: Tomas Vondra
• Re: Reseting statistics counters
  • From: Tomas Vondra
• Re: postgres performance
  • From: Richard Huxton
• Re: postgres performance
  • From: Alan Hodgson
• postgres performance
  • From: chidamparam muthusamy
• Re: Similarity search with the tsearch2 extension
  • From: Kevin Grittner
• Similarity search with the tsearch2 extension
  • From: Janek Sendrowski
• Re: WAL + SSD = slow inserts?
  • From: Rosser Schwarz
• Re: One huge db vs many small dbs
  • From: Pavel Stehule
• Re: WAL + SSD = slow inserts?
  • From: Skarsol
• Re: One huge db vs many small dbs
  • From: Josh Berkus
• Re: WAL + SSD = slow inserts?
  • From: Mark Kirkwood
• Re: One huge db vs many small dbs
  • From: Joshua D. Drake
• Re: One huge db vs many small dbs
  • From: Nicholson, Brad (Toronto, ON, CA)
• Re: Explain analyze time overhead
  • From: Kevin Grittner
• Re: WAL + SSD = slow inserts?
  • From: bricklen
• Re: Parallel Select query performance and shared buffers
  • From: Claudio Freire
• Re: WAL + SSD = slow inserts?
  • From: Scott Marlowe
• Re: WAL + SSD = slow inserts?
  • From: Jeff Janes
• Re: One huge db vs many small dbs
  • From: David Johnston
• Re: WAL + SSD = slow inserts?
  • From: Skarsol
• Re: Parallel Select query performance and shared buffers
  • From: Metin Doslu
• Re: One huge db vs many small dbs
  • From: Joe Conway
• Re: [HACKERS] Parallel Select query performance and shared buffers
  • From: Metin Doslu
• Re: [HACKERS] Parallel Select query performance and shared buffers
  • From: Andres Freund
• Re: WAL + SSD = slow inserts?
  • From: Scott Marlowe
• Re: [HACKERS] Parallel Select query performance and shared buffers
  • From: Metin Doslu
• Recommendations for partitioning?
  • From: Dave Johansen
• Re: WAL + SSD = slow inserts?
  • From: Skarsol
• Re: WAL + SSD = slow inserts?
  • From: desmodemone
• WAL + SSD = slow inserts?
  • From: Skarsol
• Re: Explain analyze time overhead
  • From: salah jubeh
• Re: One huge db vs many small dbs
  • From: bricklen
• Re: Explain analyze time overhead
  • From: Tom Lane
• Re: Explain analyze time overhead
  • From: vincent elschot
• Explain analyze time overhead
  • From: salah jubeh
• One huge db vs many small dbs
  • From: Max
• Re: Parallel Select query performance and shared buffers
  • From: Andres Freund
• Re: Parallel Select query performance and shared buffers
  • From: Metin Doslu
• Re: Parallel Select query performance and shared buffers
  • From: Andres Freund
• Re: Parallel Select query performance and shared buffers
  • From: Metin Doslu
• Re: Parallel Select query performance and shared buffers
  • From: Amit Kapila
• Parallel Select query performance and shared buffers
  • From: Metin Doslu
• Re: [HACKERS] Parallel Select query performance and shared buffers
  • From: Metin Doslu
• Re: [HACKERS] Parallel Select query performance and shared buffers
  • From: Andres Freund
• Re: Parallel Select query performance and shared buffers
  • From: Metin Doslu
• Re: [HACKERS] Parallel Select query performance and shared buffers
  • From: Metin Doslu
• Re: [HACKERS] Parallel Select query performance and shared buffers
  • From: Andres Freund
• Re: [HACKERS] Parallel Select query performance and shared buffers
  • From: Metin Doslu
• Re: [HACKERS] Parallel Select query performance and shared buffers
  • From: Claudio Freire
• Re: [HACKERS] Parallel Select query performance and shared buffers
  • From: Andres Freund
• Re: [HACKERS] Parallel Select query performance and shared buffers
  • From: Metin Doslu
• Re: [HACKERS] Parallel Select query performance and shared buffers
  • From: Metin Doslu
• Re: [HACKERS] Parallel Select query performance and shared buffers
  • From: Andres Freund
• Re: [HACKERS] Parallel Select query performance and shared buffers
  • From: Claudio Freire
• Re: Parallel Select query performance and shared buffers
  • From: Metin Doslu
• Re: [HACKERS] Parallel Select query performance and shared buffers
  • From: Metin Doslu
• Re: One query run twice in parallel results in huge performance decrease
  • From: Jan Michel
• Re: Parallel Select query performance and shared buffers
  • From: Claudio Freire
• Re: Parallel Select query performance and shared buffers
  • From: Metin Doslu
• Re: Parallel Select query performance and shared buffers
  • From: Claudio Freire
• Re: Parallel Select query performance and shared buffers
  • From: Alvaro Herrera
• Parallel Select query performance and shared buffers
  • From: Metin Doslu
• Re: One query run twice in parallel results in huge performance decrease
  • From: Scott Marlowe
• Re: One query run twice in parallel results in huge performance decrease
  • From: Jeff Janes
• Re: Speed up the query
  • From: Hengky Lie
• Re: Speed up the query
  • From: Hengky Lie
• Re: Speed up the query
  • From: Hengky Lie
• Re: Speed up the query
  • From: Kevin Grittner
• Re: Speed up the query
  • From: Hengky Liwandouw
• Re: Speed up the query
  • From: Hengky Liwandouw
• Re: Speed up the query
  • From: Andreas Kretschmer
• Re: Speed up the query
  • From: Andreas Kretschmer
• Re: Speed up the query
  • From: Torsten Förtsch
• Re: Speed up the query
  • From: desmodemone
• Re: Speed up the query
  • From: Hengky Liwandouw
• Re: Speed up the query
  • From: Andreas Kretschmer
• Re: Speed up the query
  • From: Hengky Liwandouw
• Re: Speed up the query
  • From: Andreas Kretschmer
• Speed up the query
  • From: Hengky Liwandouw
• Re: One query run twice in parallel results in huge performance decrease
  • From: Jan Michel
• Re: One query run twice in parallel results in huge performance decrease
  • From: Tom Lane
• Re: One query run twice in parallel results in huge performance decrease
  • From: Jan Michel
• Re: One query run twice in parallel results in huge performance decrease
  • From: Jeff Janes
• One query run twice in parallel results in huge performance decrease
  • From: Jan Michel
• Re: Postgresql in a Virtual Machine
  • From: Michael Paquier
• Re: Postgresql in a Virtual Machine
  • From: Scott Marlowe
• Re: Postgresql in a Virtual Machine
  • From: Dong Ye
• Re: Postgresql in a Virtual Machine
  • From: Gudmundsson Martin (mg)
• Re: Postgresql in a Virtual Machine
  • From: Dong Ye
• Re: Postgresql in a Virtual Machine
  • From: David Kerr
• Re: Postgresql in a Virtual Machine
  • From: Craig James
• Re: Postgresql in a Virtual Machine
  • From: Ben Chobot
• Re: Postgresql in a Virtual Machine
  • From: Merlin Moncure
• Re: Postgresql in a Virtual Machine
  • From: Josh Berkus
• Re: Postgresql in a Virtual Machine
  • From: Craig James
• Re: Postgresql in a Virtual Machine
  • From: David Boreham
• Re: Postgresql in a Virtual Machine
  • From: Andrew Dunstan
• Re: Postgresql in a Virtual Machine
  • From: Andrew Dunstan
• Re: Postgresql in a Virtual Machine
  • From: Craig James
• Re: Postgresql in a Virtual Machine
  • From: Stephen Frost
• Re: Postgresql in a Virtual Machine
  • From: Boszormenyi Zoltan
• Re: Postgresql in a Virtual Machine
  • From: Rafael Martinez
• Re: Postgresql in a Virtual Machine
  • From: Xenofon Papadopoulos
• Re: Postgresql in a Virtual Machine
  • From: David Lang
• Re: Postgresql in a Virtual Machine
  • From: Xenofon Papadopoulos
• Re: Postgresql in a Virtual Machine
  • From: Merlin Moncure
• Re: Postgresql in a Virtual Machine
  • From: David Lang
• Re: Postgresql in a Virtual Machine
  • From: Merlin Moncure
• Re: Postgresql in a Virtual Machine
  • From: Mark Kirkwood
• Re: Postgresql in a Virtual Machine
  • From: Gudmundsson Martin (mg)
• Re: Postgresql in a Virtual Machine
  • From: Andrew Dunstan
• Re: Postgresql in a Virtual Machine
  • From: Heikki Linnakangas
• Re: Postgresql in a Virtual Machine
  • From: Gavin Flower
• Postgresql in a Virtual Machine
  • From: Lee Nguyen
• Re: UNION versus SUB SELECT
  • From: Robert DiFalco
• Re: UNION versus SUB SELECT
  • From: Merlin Moncure
• Re: Query in cache
  • From: Rogerio Pereira
• Re: UNION versus SUB SELECT
  • From: Robert DiFalco
• Re: UNION versus SUB SELECT
  • From: bricklen
• Re: UNION versus SUB SELECT
  • From: bricklen
• Re: UNION versus SUB SELECT
  • From: Robert DiFalco
• Re: UNION versus SUB SELECT
  • From: Robert DiFalco
• Re: UNION versus SUB SELECT
  • From: desmodemone
• Re: UNION versus SUB SELECT
  • From: Robert DiFalco
• Re: UNION versus SUB SELECT
  • From: desmodemone
• UNION versus SUB SELECT
  • From: Robert DiFalco
• Error install -pgmemcache
  • From: Rogerio Pereira
• Re: Query in cache
  • From: Rogerio Pereira
• Re: Query in cache
  • From: ktm@xxxxxxxx
• Re: Query in cache
  • From: Sergey Konoplev
• Re: Query in cache
  • From: salah jubeh
• Re: Error Broken pipe in log postgres
  • From: Craig James
• Error Broken pipe in log postgres
  • From: Rogerio Pereira
• Re: Query in cache
  • From: ktm@xxxxxxxx
• Re: Query in cache
  • From: Andreas Kretschmer
• Query in cache
  • From: Rogerio Pereira
• Re: Reseting statistics counters
  • From: Strahinja Kustudić
• General slowness when retrieving a relatively small number of rows
  • From: Patrick Krecker
• Re: Bad plan choices & statistic targets with a GIN index
  • From: Tom Lane
• Bad plan choices & statistic targets with a GIN index
  • From: Dieter Komendera
• Re: Performance bug in prepared statement binding in 9.2?
  • From: Tom Lane
• Re: Performance bug in prepared statement binding in 9.2?
  • From: Josh Berkus
• Re: Horrific time for getting 1 record from an index?
  • From: Merlin Moncure
• CREATE TABLE AS WITH FREEZE ?
  • From: Marc Mamin
• Re: BitMap Heap Scan & BitMap Index Scan
  • From: Torsten Förtsch
• Re: Order By Clause, Slows Query Performance?
  • From: Albe Laurenz
• Re: Performance bug in prepared statement binding in 9.2?
  • From: Tom Lane
• Re: Order By Clause, Slows Query Performance?
  • From: Michael Paquier
• Re: BitMap Heap Scan & BitMap Index Scan
  • From: Michael Paquier
• Order By Clause, Slows Query Performance?
  • From: monalee_dba
• Re: Performance bug in prepared statement binding in 9.2?
  • From: Kevin Grittner
• BitMap Heap Scan & BitMap Index Scan
  • From: monalee_dba
• Re: Horrific time for getting 1 record from an index?
  • From: Jim Nasby
• Re: Horrific time for getting 1 record from an index?
  • From: Jeff Janes
• Re: postgresql recommendation memory
  • From: Евгений Селявка
• Unexpected slow query time when joining small table with large table
  • From: Ryan LeCompte
• Re: Horrific time for getting 1 record from an index?
  • From: Jeff Janes
• Re: Horrific time for getting 1 record from an index?
  • From: Jim Nasby
• Re: Horrific time for getting 1 record from an index?
  • From: Jeff Janes
• Re: Horrific time for getting 1 record from an index?
  • From: Daniel Farina
• Re: Horrific time for getting 1 record from an index?
  • From: Jim Nasby
• Re: Horrific time for getting 1 record from an index?
  • From: Daniel Farina
• Horrific time for getting 1 record from an index?
  • From: Jim Nasby
• Re: postgresql recommendation memory
  • From: Jeff Janes
• Re: postgresql recommendation memory
  • From: Sergey Konoplev
• Re: postgresql recommendation memory
  • From: Sergey Konoplev
• Re: Planner performance extremely affected by an hanging transaction (20-30 times)?
  • From: Tom Lane
• Re: postgresql recommendation memory
  • From: ktm@xxxxxxxx
• Re: postgresql recommendation memory
  • From: Scott Marlowe
• Re: Size of IN list affects query plan
  • From: Jan Walter
• Re: postgresql recommendation memory
  • From: Евгений Селявка
• Re: postgresql recommendation memory
  • From: Sergey Konoplev
• Re: Performance bug in prepared statement binding in 9.2?
  • From: Tom Lane
• Re: Size of IN list affects query plan
  • From: Tom Lane
• Re: Size of IN list affects query plan
  • From: bricklen
• Size of IN list affects query plan
  • From: Jan Walter
• Re: postgresql recommendation memory
  • From: Евгений Селявка
• Re: postgresql recommendation memory
  • From: Евгений Селявка
• Re: postgresql recommendation memory
  • From: David Rees
• Re: postgresql recommendation memory
  • From: Merlin Moncure
• Re: Slow index scan on B-Tree index over timestamp field
  • From: Caio Casimiro
• Re: Slow index scan on B-Tree index over timestamp field
  • From: Jeff Janes
• Re: postgresql recommendation memory
  • From: Scott Marlowe
• Re: postgresql recommendation memory
  • From: Scott Marlowe
• Re: Slow index scan on B-Tree index over timestamp field
  • From: Merlin Moncure
• Re: postgresql recommendation memory
  • From: Scott Marlowe
• Re: Trees: integer[] outperformed by ltree
  • From: Merlin Moncure
• Re: postgresql recommendation memory
  • From: Евгений Селявка
• Re: Trees: integer[] outperformed by ltree
  • From: Jan Walter
• Re: postgresql recommendation memory
  • From: Scott Marlowe
• Re: postgresql recommendation memory
  • From: Michael Paquier
• Re: Trees: integer[] outperformed by ltree
  • From: Merlin Moncure
• Re: Trees: integer[] outperformed by ltree
  • From: Jan Walter
• Re: postgresql recommendation memory
  • From: Josh Berkus
• Re: Trees: integer[] outperformed by ltree
  • From: Merlin Moncure
• Re: Trees: integer[] outperformed by ltree
  • From: Merlin Moncure
• Re: Slow index scan on B-Tree index over timestamp field
  • From: Jeff Janes
• Re: Slow index scan on B-Tree index over timestamp field
  • From: Igor Neyman
• Trees: integer[] outperformed by ltree
  • From: Jan Walter
• Re: ORDER BY performance deteriorates very quickly as dataset grows
  • From: aasat
• Re: ORDER BY performance deteriorates very quickly as dataset grows
  • From: aasat
• Re: postgresql recommendation memory
  • From: Евгений Селявка
• ORDER BY performance deteriorates very quickly as dataset grows
  • From: Standa K.
• Re: Slow index scan on B-Tree index over timestamp field
  • From: Caio Casimiro
• Re: Slow index scan on B-Tree index over timestamp field
  • From: desmodemone
• Re: Slow index scan on B-Tree index over timestamp field
  • From: Caio Casimiro
• Re: Slow index scan on B-Tree index over timestamp field
  • From: Caio Casimiro
• Re: Slow index scan on B-Tree index over timestamp field
  • From: Igor Neyman
• Re: Slow index scan on B-Tree index over timestamp field
  • From: Elliot
• Re: Slow index scan on B-Tree index over timestamp field
  • From: Caio Casimiro