Postgres Performance Date Index

• Thread Index

• Re: No index only scan on md5 index
  • From: Tom Lane
• Re: No index only scan on md5 index
  • From: David G. Johnston
• No index only scan on md5 index
  • From: Adam Brusselback
• Re: Query that took a lot of time in Postgresql when not using trim in order by
  • From: Blas Pico
• Re: Query that took a lot of time in Postgresql when not using trim in order by
  • From: Evgeniy Shishkin
• Re: Query that took a lot of time in Postgresql when not using trim in order by
  • From: Alex Ignatov
• Query that took a lot of time in Postgresql when not using trim in order by
  • From: Blas Pico
• Re: Why is now()::date so much faster than current_date
  • From: Tom Lane
• Re: Why is now()::date so much faster than current_date
  • From: David Rowley
• Why is now()::date so much faster than current_date
  • From: Thomas Kellerer
• Re: Recursive query performance issue
  • From: Merlin Moncure
• Re: Recursive query performance issue
  • From: Jamie Koceniak
• Re: Queries getting canceled inside a proc that seems to slow down randomly
  • From: Jim Nasby
• Re: Hanging query on a fresh restart
  • From: Jim Nasby
• Re: Simple delete query is taking too long (never ends)
  • From: Scott Marlowe
• Re: Simple delete query is taking too long (never ends)
  • From: Merlin Moncure
• Re: Simple delete query is taking too long (never ends)
  • From: Tom Lane
• Re: Simple delete query is taking too long (never ends)
  • From: Merlin Moncure
• Re: Simple delete query is taking too long (never ends)
  • From: Craig James
• Re: Simple delete query is taking too long (never ends)
  • From: Tom Lane
• Re: Simple delete query is taking too long (never ends)
  • From: Merlin Moncure
• Re: Simple delete query is taking too long (never ends)
  • From: Tom Lane
• Simple delete query is taking too long (never ends)
  • From: Massalin Yerzhan
• Queries getting canceled inside a proc that seems to slow down randomly
  • From: Skarsol
• Re: Slow 3 Table Join with v bad row estimate
  • From: David Osborne
• Hanging query on a fresh restart
  • From: Jason Jho
• Re: Slow 3 Table Join with v bad row estimate
  • From: Igor Neyman
• Re: Slow 3 Table Join with v bad row estimate
  • From: David Osborne
• Re: Slow 3 Table Join with v bad row estimate
  • From: Tom Lane
• Re: Slow 3 Table Join with v bad row estimate
  • From: David Osborne
• Re: Slow 3 Table Join with v bad row estimate
  • From: Tom Lane
• Slow 3 Table Join with v bad row estimate
  • From: David Osborne
• Re: querying jsonb for arrays inside a hash
  • From: Joe Van Dyk
• Re: querying jsonb for arrays inside a hash
  • From: Tom Lane
• querying jsonb for arrays inside a hash
  • From: Joe Van Dyk
• Re: HASH
  • From: Jeff Janes
• Re: Yet another abort-early plan disaster on 9.3
  • From: Evgeniy Shishkin
• HASH
  • From: Artem Tomyuk
• Re: Slow query in trigger function
  • From: Guido Niewerth
• Re: GIN index always doing Re-check condition, postgres 9.1
  • From: Andrey Osenenko
• Re: GIN index always doing Re-check condition, postgres 9.1
  • From: Jeff Janes
• Re: GIN index always doing Re-check condition, postgres 9.1
  • From: Jim Nasby
• Re: Slow query in trigger function
  • From: Tom Lane
• Re: Slow query in trigger function
  • From: Guido Niewerth
• Re: Slow query in trigger function
  • From: Tom Lane
• Re: PostgreSQL limitation
  • From: Michael Paquier
• PostgreSQL limitation
  • From: FattahRozzaq
• Slow query in trigger function
  • From: Guido Niewerth
• Re: GIN index always doing Re-check condition, postgres 9.1
  • From: Andrey Osenenko
• Re: GIN index always doing Re-check condition, postgres 9.1
  • From: Jeff Janes
• GIN index always doing Re-check condition, postgres 9.1
  • From: Andrey Osenenko
• Re: Query optimizer plans with very small selectivity estimates
  • From: Josh Berkus
• Re: Query optimizer plans with very small selectivity estimates
  • From: Tom Lane
• Query optimizer plans with very small selectivity estimates
  • From: Matthew Bellew
• Re: Scalability to more than 64 cores With PG 9.4 and RHEL 7.1 Kernel 3.10
  • From: Alex Ignatov
• Re: Query planner wants to use seq scan
  • From: Bertrand Paquet
• Re: Query planner wants to use seq scan
  • From: Alex Ignatov
• Scalability to more than 64 cores With PG 9.4 and RHEL 7.1 Kernel 3.10
  • From: Javier Muro
• Re: Query planner wants to use seq scan
  • From: Jim Nasby
• Re: Partition Constraint Exclusion Limits
  • From: Jim Nasby
• Re: Query planner wants to use seq scan
  • From: Bertrand Paquet
• Re: Partition Constraint Exclusion Limits
  • From: Vitalii Tymchyshyn
• Re: Partition Constraint Exclusion Limits
  • From: David G. Johnston
• Partition Constraint Exclusion Limits
  • From: GMail
• Re: Query planner wants to use seq scan
  • From: Bertrand Paquet
• Re: Query planner wants to use seq scan
  • From: Bertrand Paquet
• Re: Query planner wants to use seq scan
  • From: Bertrand Paquet
• Re: Query planner wants to use seq scan
  • From: Tom Lane
• Re: Query planner wants to use seq scan
  • From: Alex Ignatov
• Re: Query planner wants to use seq scan
  • From: Bertrand Paquet
• Re: Query planner wants to use seq scan
  • From: Alex Ignatov
• Re: Query planner wants to use seq scan
  • From: Bertrand Paquet
• Re: Query planner wants to use seq scan
  • From: Alex Ignatov
• Query planner wants to use seq scan
  • From: Bertrand Paquet
• Re: GroupAggregate and Integer Arrays
  • From: Merlin Moncure
• Re: GroupAggregate and Integer Arrays
  • From: David Osborne
• Re: Recursive query performance issue
  • From: Merlin Moncure
• Re: Recursive query performance issue
  • From: Jamie Koceniak
• Re: Recursive query performance issue
  • From: Jamie Koceniak
• Re: Recursive query performance issue
  • From: Jamie Koceniak
• Re: Recursive query performance issue
  • From: Jamie Koceniak
• Re: Recursive query performance issue
  • From: Jamie Koceniak
• Re: GroupAggregate and Integer Arrays
  • From: Marc Mamin
• Re: GroupAggregate and Integer Arrays
  • From: Jeff Janes
• Re: Recursive query performance issue
  • From: Pavel Stehule
• Re: GroupAggregate and Integer Arrays
  • From: Merlin Moncure
• Re: GroupAggregate and Integer Arrays
  • From: David Osborne
• Re: GroupAggregate and Integer Arrays
  • From: Jeff Janes
• GroupAggregate and Integer Arrays
  • From: David Osborne
• Re: Recursive query performance issue
  • From: vincent elschot
• Re: Recursive query performance issue
  • From: Merlin Moncure
• Re: Recursive query performance issue
  • From: Pavel Stehule
• Re: Recursive query performance issue
  • From: Pavel Stehule
• Re: Recursive query performance issue
  • From: Pavel Stehule
• Re: Recursive query performance issue
  • From: Merlin Moncure
• Re: Recursive query performance issue
  • From: Pavel Stehule
• Recursive query performance issue
  • From: Jamie Koceniak
• Re: SELECT slows down on sixth execution
  • From: Pavel Stehule
• Re: SELECT slows down on sixth execution
  • From: Jonathan Rogers
• Re: SELECT slows down on sixth execution
  • From: Pavel Stehule
• Re: SELECT slows down on sixth execution
  • From: Thomas Kellerer
• Re: SELECT slows down on sixth execution
  • From: Merlin Moncure
• Re: One long transaction or multiple short transactions?
  • From: Jim Nasby
• Re: One long transaction or multiple short transactions?
  • From: Andres Freund
• Re: One long transaction or multiple short transactions?
  • From: Jim Nasby
• Re: SELECT slows down on sixth execution
  • From: Pavel Stehule
• Re: SELECT slows down on sixth execution
  • From: Yves Dorfsman
• Re: SELECT slows down on sixth execution
  • From: Pavel Stehule
• Re: SELECT slows down on sixth execution
  • From: Jonathan Rogers
• Re: SELECT slows down on sixth execution
  • From: Jonathan Rogers
• Re: query partitioned table is very slow
  • From: Tom Lane
• query partitioned table is very slow
  • From: Vladimir Yavoskiy
• Re: SELECT slows down on sixth execution
  • From: Albe Laurenz
• Re: SELECT slows down on sixth execution
  • From: Jonathan Rogers
• Re: SELECT slows down on sixth execution
  • From: Pavel Stehule
• Re: SELECT slows down on sixth execution
  • From: Albe Laurenz
• SELECT slows down on sixth execution
  • From: Jonathan Rogers
• Re: Having some problems with concurrent COPY commands
  • From: David Rowley
• Re: Having some problems with concurrent COPY commands
  • From: Shaun Thomas
• Re: Having some problems with concurrent COPY commands
  • From: Andres Freund
• Re: Having some problems with concurrent COPY commands
  • From: Shaun Thomas
• Re: Having some problems with concurrent COPY commands
  • From: Heikki Linnakangas
• V8 optimisation (if you're using javascript in postgres)
  • From: Graeme B. Bell
• Re: Having some problems with concurrent COPY commands
  • From: Shaun Thomas
• Re: Having some problems with concurrent COPY commands
  • From: Jeff Janes
• Re: Having some problems with concurrent COPY commands
  • From: Andres Freund
• Having some problems with concurrent COPY commands
  • From: Shaun Thomas
• Re: 3000x Slower query when using Foreign Data Wrapper vs. local
  • From: Mohammad Habbab
• Re: 3000x Slower query when using Foreign Data Wrapper vs. local
  • From: desmodemone
• Re: 3000x Slower query when using Foreign Data Wrapper vs. local
  • From: Mohammad Habbab
• Re: 3000x Slower query when using Foreign Data Wrapper vs. local
  • From: desmodemone
• 3000x Slower query when using Foreign Data Wrapper vs. local
  • From: Mohammad Habbab
• Re: LIMIT 1 poor query plan
  • From: Marcio Ribeiro
• Re: LIMIT 1 poor query plan
  • From: Tom Lane
• LIMIT 1 poor query plan
  • From: Marcio Ribeiro
• Re: Re: Multi processor server overloads occationally with system process while running postgresql-9.4
  • From: Kevin Grittner
• Re: One long transaction or multiple short transactions?
  • From: Graeme B. Bell
• Re: One long transaction or multiple short transactions?
  • From: Laurent Martelli
• Re: One long transaction or multiple short transactions?
  • From: ktm@xxxxxxxx
• Re: One long transaction or multiple short transactions?
  • From: Carlo
• Re: One long transaction or multiple short transactions?
  • From: ktm@xxxxxxxx
• Re: One long transaction or multiple short transactions?
  • From: Carlo
• Re: large object write performance
  • From: Bram Van Steenlandt
• Re: large object write performance
  • From: Graeme B. Bell
• Re: large object write performance
  • From: Bram Van Steenlandt
• Re: large object write performance
  • From: Graeme B. Bell
• Re: large object write performance
  • From: Bram Van Steenlandt
• Re: large object write performance
  • From: Bram Van Steenlandt
• Re: large object write performance
  • From: Graeme B. Bell
• Re: large object write performance
  • From: Bram Van Steenlandt
• Re: large object write performance
  • From: Graeme B. Bell
• Re: large object write performance
  • From: Graeme B. Bell
• Re: large object write performance
  • From: Graeme B. Bell
• large object write performance
  • From: Bram Van Steenlandt
• Re: One long transaction or multiple short transactions?
  • From: Graeme B. Bell
• Re: One long transaction or multiple short transactions?
  • From: Carlo
• Re: shared-buffers set to 24GB but the RAM only use 4-5 GB average
  • From: Merlin Moncure
• Re: shared-buffers set to 24GB but the RAM only use 4-5 GB average
  • From: Scott Marlowe
• Re: shared-buffers set to 24GB but the RAM only use 4-5 GB average
  • From: FattahRozzaq
• Re: Re: Multi processor server overloads occationally with system process while running postgresql-9.4
  • From: Scott Marlowe
• Re: shared-buffers set to 24GB but the RAM only use 4-5 GB average
  • From: Josh Berkus
• Re: Multi processor server overloads occationally with system process while running postgresql-9.4
  • From: ajaykbs
• Re: shared-buffers set to 24GB but the RAM only use 4-5 GB average
  • From: Merlin Moncure
• Re: shared-buffers set to 24GB but the RAM only use 4-5 GB average
  • From: Scott Marlowe
• Re: One long transaction or multiple short transactions?
  • From: Igor Neyman
• Re: shared-buffers set to 24GB but the RAM only use 4-5 GB average
  • From: FattahRozzaq
• One long transaction or multiple short transactions?
  • From: Carlo
• Re: shared-buffers set to 24GB but the RAM only use 4-5 GB average
  • From: Igor Neyman
• Re: shared-buffers set to 24GB but the RAM only use 4-5 GB average
  • From: Igor Neyman
• Re: shared-buffers set to 24GB but the RAM only use 4-5 GB average
  • From: Merlin Moncure
• shared-buffers set to 24GB but the RAM only use 4-5 GB average
  • From: FattahRozzaq
• Re: Multi processor server overloads occationally with system process while running postgresql-9.4
  • From: ajaykbs
• Re: Multi processor server overloads occationally with system process while running postgresql-9.4
  • From: Andres Freund
• Re: Multi processor server overloads occationally with system process while running postgresql-9.4
  • From: Wei Shan
• Re: Multi processor server overloads occationally with system process while running postgresql-9.4
  • From: Gavin Flower
• Multi processor server overloads occationally with system process while running postgresql-9.4
  • From: ajaykbs
• Re: Queries Per Second (QPS)
  • From: Josh Berkus
• Re: dump restoration performance
  • From: Michael Paquier
• dump restoration performance
  • From: rlemaroi
• Re: Performance problem with gin index
  • From: Bertrand Paquet
• Re: Performance problem with gin index
  • From: Jeff Janes
• Re: Another parallel postgres project...
  • From: Corey Huinker
• Re: Performance problem with gin index
  • From: ktm@xxxxxxxx
• Performance problem with gin index
  • From: Bertrand Paquet
• Another parallel postgres project...
  • From: Graeme B. Bell
• Re: Queries Per Second (QPS)
  • From: Jeff Janes
• Re: Queries Per Second (QPS)
  • From: Guillaume Lelarge
• Re: Queries Per Second (QPS)
  • From: Guillaume Lelarge
• Queries Per Second (QPS)
  • From: Adam Scott
• Re: Occasional Really Slow Running Updates/Inserts
  • From: Dave Stibrany
• Re: degrading inser performance
  • From: Dave Cramer
• Re: Occasional Really Slow Running Updates/Inserts
  • From: ktm@xxxxxxxx
• Occasional Really Slow Running Updates/Inserts
  • From: Dave Stibrany
• Re: degrading inser performance
  • From: Eildert Groeneveld
• Re: degrading inser performance
  • From: Matheus de Oliveira
• Re: degrading inser performance
  • From: Eildert Groeneveld
• Re: degrading inser performance
  • From: Ladislav Lenart
• degrading inser performance
  • From: Eildert Groeneveld
• Re: VACUUM VERBOSE ANALYZE taking long time to process.
  • From: Ben Chobot
• VACUUM VERBOSE ANALYZE taking long time to process.
  • From: anil7385
• Re: Server slowing down over time
  • From: Jim Nasby
• Announcing the public availability of the TPCx-V prototype
  • From: Reza Taheri
• Re: pg_stat_all_indexes understand
  • From: Bruce Momjian
• Re: query with pg_trgm sometimes very slow
  • From: Merlin Moncure
• Re: query with pg_trgm sometimes very slow
  • From: Tomas Vondra
• Re: query with pg_trgm sometimes very slow
  • From: Merlin Moncure
• Re: Server slowing down over time
  • From: Tomas Vondra
• Re: Server slowing down over time
  • From: Wei Shan
• Re: query with pg_trgm sometimes very slow
  • From: Claudio Freire
• Re: PostgreSQL Tuning for Messaging/Messenger/Chatting Application
  • From: Sridhar N Bamandlapally
• Re: Server slowing down over time
  • From: Igor Neyman
• Server slowing down over time
  • From: Jean Cavallo
• Re: query with pg_trgm sometimes very slow
  • From: Jeff Janes
• query with pg_trgm sometimes very slow
  • From: Volker Böhm
• PostgreSQL Tuning for Messaging/Messenger/Chatting Application
  • From: FattahRozzaq
• Re: [PERFORM] Re: Query > 1000× slowdown after adding datetime comparison
  • From: 林士博
• Re: [PERFORM] Re: Query > 1000× slowdown after adding datetime comparison
  • From: 林士博
• Re: Re: Query > 1000× slowdown after adding datetime comparison
  • From: twoflower
• Re: [PERFORM] Re: Query > 1000× slowdown after adding datetime comparison
  • From: 林士博
• Re: Re: Query > 1000× slowdown after adding datetime comparison
  • From: twoflower
• Re: [PERFORM] Re: Query > 1000× slowdown after adding datetime comparison
  • From: Stefan Keller
• Re: Re: Query > 1000× slowdown after adding datetime comparison
  • From: twoflower
• Re: [PERFORM] Re: Query > 1000× slowdown after adding datetime comparison
  • From: Stefan Keller
• Re: Re: Query > 1000× slowdown after adding datetime comparison
  • From: twoflower
• Re: [PERFORM] Re: Query > 1000× slowdown after adding datetime comparison
  • From: David G. Johnston
• Re: [PERFORM] Re: Query > 1000× slowdown after adding datetime comparison
  • From: David G. Johnston
• Re: Query > 1000× slowdown after adding datetime comparison
  • From: twoflower
• Re: Query > 1000× slowdown after adding datetime comparison
  • From: twoflower
• Re: [PERFORM] Query > 1000× slowdown after adding datetime comparison
  • From: David G. Johnston
• Re: Query > 1000× slowdown after adding datetime comparison
  • From: Tomas Vondra
• Query > 1000× slowdown after adding datetime comparison
  • From: twoflower
• Re: is there any way we can push join predicate into inner table
  • From: Tom Lane
• is there any way we can push join predicate into inner table
  • From: =?gb18030?b?sKTM38jL?=
• Re: Gist indexing performance with cidr types
  • From: Henrik Thostrup Jensen
• Re: Gist indexing performance with cidr types
  • From: Emre Hasegeli
• Re: Gist indexing performance with cidr types
  • From: Henrik Thostrup Jensen
• Re: Gist indexing performance with cidr types
  • From: Henrik Thostrup Jensen
• Re: Index creation running now for 14 hours
  • From: Peter Geoghegan
• Re: Index creation running now for 14 hours
  • From: Tomas Vondra
• Re: Index creation running now for 14 hours
  • From: Tomas Vondra
• Re: Index creation running now for 14 hours
  • From: Tory M Blue
• Re: Index creation running now for 14 hours
  • From: Qingqing Zhou
• Re: Index creation running now for 14 hours
  • From: Tory M Blue
• Re: Index creation running now for 14 hours
  • From: Igor Neyman
• Re: Index creation running now for 14 hours
  • From: Tory M Blue
• Re: Index creation running now for 14 hours
  • From: Igor Neyman
• Index creation running now for 14 hours
  • From: Tory M Blue
• Re: Gist indexing performance with cidr types
  • From: Jeff Janes
• Re: Gist indexing performance with cidr types
  • From: Emre Hasegeli
• Re: Gist indexing performance with cidr types
  • From: Henrik Thostrup Jensen
• Re: Gist indexing performance with cidr types
  • From: Emre Hasegeli
• Re: Gist indexing performance with cidr types
  • From: Henrik Thostrup Jensen
• Re: Gist indexing performance with cidr types
  • From: Henrik Thostrup Jensen
• Re: Gist indexing performance with cidr types
  • From: Emre Hasegeli
• Re: Long running query: How to monitor the progress
  • From: Tom Lane
• Gist indexing performance with cidr types
  • From: Henrik Thostrup Jensen
• Long running query: How to monitor the progress
  • From: Johann Spies
• Re: query not using GIN index
  • From: Jeff Janes
• Re: query not using GIN index
  • From: Guo, Yun
• Re: query not using GIN index
  • From: Guo, Yun
• Re: problem with select *
  • From: Andrew Dunstan
• Re: Performance bottleneck due to array manipulation
  • From: Genc, Ömer
• Re: problem with select *
  • From: Andreas Joseph Krogh
• Re: problem with select *
  • From: Wei Shan
• problem with select *
  • From: bhuvan Mitra
• Re: query not using GIN index
  • From: Tomas Vondra
• query not using GIN index
  • From: Guo, Yun
• Re: Performance bottleneck due to array manipulation
  • From: Igor Neyman
• Re: Performance bottleneck due to array manipulation
  • From: Félix GERZAGUET
• Re: Performance bottleneck due to array manipulation
  • From: Tom Lane
• Performance bottleneck due to array manipulation
  • From: Genc, Ömer
• Re: Most efficient way of querying M 'related' tables where N out of M may contain the key
  • From: David G. Johnston
• Re: Most efficient way of querying M 'related' tables where N out of M may contain the key
  • From: Stephane Bailliez
• Re: Most efficient way of querying M 'related' tables where N out of M may contain the key
  • From: David G. Johnston
• Most efficient way of querying M 'related' tables where N out of M may contain the key
  • From: Stephane Bailliez
• Re: incredible surprise news from intel/micron right now...
  • From: Graeme B. Bell
• Re: Strange query stalls on replica in 9.3.9
  • From: Jeff Janes
• Re: Strange query stalls on replica in 9.3.9
  • From: Jeff Janes
• Re: Strange query stalls on replica in 9.3.9
  • From: Josh Berkus
• Re: Slow Query
  • From: 林士博
• Re: Slow Query
  • From: 林士博
• Re: Slow Query
  • From: robbyc
• Re: Strange query stalls on replica in 9.3.9
  • From: Jeff Janes
• Re: Strange query stalls on replica in 9.3.9
  • From: Kevin Grittner
• Strange query stalls on replica in 9.3.9
  • From: Josh Berkus
• Re: Slow Query
  • From: 林士博
• Re: Slow Query
  • From: robbyc
• Re: Slow Query
  • From: Vik Fearing
• Re: Query Plan Performance on Partitioned Table
  • From: Rural Hunter
• Re: Query Plan Performance on Partitioned Table
  • From: Pietro Pugni
• Re: Slow Query
  • From: Venkata Balaji N
• Re: Slow Query
  • From: robbyc
• Re: Slow Query
  • From: Venkata Balaji N
• Slow Query
  • From: robbyc
• Re: Query Plan Performance on Partitioned Table
  • From: Rural Hunter
• Re: Query Plan Performance on Partitioned Table
  • From: Pietro Pugni
• Re: Query Plan Performance on Partitioned Table
  • From: Rural Hunter
• Re: Query Plan Performance on Partitioned Table
  • From: Maxim Boguk
• Re: Query Plan Performance on Partitioned Table
  • From: Rural Hunter
• Re: Query Plan Performance on Partitioned Table
  • From: Rural Hunter
• Re: Query Plan Performance on Partitioned Table
  • From: Maxim Boguk
• Re: Query Plan Performance on Partitioned Table
  • From: Rural Hunter
• Re: Query Plan Performance on Partitioned Table
  • From: Maxim Boguk
• Query Plan Performance on Partitioned Table
  • From: Rural Hunter
• Re: Slow HashAggregate/cache access
  • From: David Rowley
• Re: Slow HashAggregate/cache access
  • From: Andreas Joseph Krogh
• Re: Slow HashAggregate/cache access
  • From: Alexandre de Arruda Paes
• Re: Slow HashAggregate/cache access
  • From: Alexandre de Arruda Paes
• Re: Slow HashAggregate/cache access
  • From: David Rowley
• Re: Slow HashAggregate/cache access
  • From: David Rowley
• Re: Slow HashAggregate/cache access
  • From: Andreas Joseph Krogh
• Re: Slow HashAggregate/cache access
  • From: Alexandre de Arruda Paes
• Re: Slow HashAggregate/cache access
  • From: Andreas Joseph Krogh
• Re: Slow HashAggregate/cache access
  • From: Alexandre de Arruda Paes
• Re: Slow HashAggregate/cache access
  • From: Maxim Boguk
• Re: Slow HashAggregate/cache access
  • From: Kevin Grittner
• Re: Performance issue with NestedLoop query
  • From: Qingqing Zhou
• Re: Performance issue with NestedLoop query
  • From: Ram N
• Slow HashAggregate/cache access
  • From: Alexandre de Arruda Paes
• Re: Performance issue with NestedLoop query
  • From: Qingqing Zhou
• Re: Performance issue with NestedLoop query
  • From: Matheus de Oliveira
• Re: Performance issue with NestedLoop query
  • From: Matheus de Oliveira
• Re: Performance issue with NestedLoop query
  • From: Ram N
• Re: Performance issue with NestedLoop query
  • From: Qingqing Zhou
• Performance issue with NestedLoop query
  • From: Ram N
• Re: Are many idle connections bad?
  • From: Alex Hunsaker
• incredible surprise news from intel/micron right now...
  • From: Graeme B. Bell
• Re: autofreeze/vacuuming - avoiding the random performance hit
  • From: Graeme B. Bell
• Re: autofreeze/vacuuming - avoiding the random performance hit
  • From: Wei Shan
• autofreeze/vacuuming - avoiding the random performance hit
  • From: Graeme B. Bell
• Re: Any ideas how can I speed up this query?
  • From: 林士博
• Re: Any ideas how can I speed up this query?
  • From: Graeme B. Bell
• Any ideas how can I speed up this query?
  • From: Priyank Tiwari
• Re: Are many idle connections bad?
  • From: Jeff Janes
• Re: Are many idle connections bad?
  • From: Craig James
• Re: Are many idle connections bad?
  • From: Tom Lane
• Are many idle connections bad?
  • From: Craig James
• Re: hyperthreadin low performance
  • From: Mark Kirkwood
• Re: bitmap heap scan recheck for gin/fts with no lossy blocks
  • From: Jeff Janes
• Re: bitmap heap scan recheck for gin/fts with no lossy blocks
  • From: Laurent Debacker
• Re: bitmap heap scan recheck for gin/fts with no lossy blocks
  • From: Jeff Janes
• bitmap heap scan recheck for gin/fts with no lossy blocks
  • From: Laurent Debacker
• parallelisation provides postgres performance (script example + ppt slides)
  • From: Graeme B. Bell
• Re: hyperthreadin low performance (and some discussion about benchmarking)
  • From: Graeme B. Bell
• Re: hyperthreadin low performance
  • From: domenico febbo
• Re: How to find the culprit in server load spikes?
  • From: Jeff Janes
• Re: How to find the culprit in server load spikes?
  • From: Kevin Grittner
• How to find the culprit in server load spikes?
  • From: Moreno Andreo
• Re: hyperthreadin low performance
  • From: Mark Kirkwood
• Re: hyperthreadin low performance
  • From: David Rowley
• hyperthreadin low performance
  • From: Jeison Bedoya Delgado
• Re: Different plan for very similar queries
  • From: Peter J. Holzer
• Re: intel s3500 -- hot stuff
  • From: Julien Rouhaud
• Re: Insert vs Update
  • From: Guillaume Lelarge
• Re: Insert vs Update
  • From: David G. Johnston
• Re: Insert vs Update
  • From: Michael Nolan
• Re: Insert vs Update
  • From: Robert DiFalco
• Re: Insert vs Update
  • From: David G. Johnston
• Re: Insert vs Update
  • From: Robert DiFalco
• Re: Insert vs Update
  • From: David G. Johnston
• Re: Insert vs Update
  • From: Robert DiFalco
• Re: Insert vs Update
  • From: David G. Johnston
• Re: Insert vs Update
  • From: Michael Nolan
• Re: Insert vs Update
  • From: David G. Johnston
• Insert vs Update
  • From: Robert DiFalco
• Re: Query planner not using indexes with JOIN query and OR clause
  • From: Ben Hoyt
• Re: Query planner not using indexes with JOIN query and OR clause
  • From: Merlin Moncure
• Re: [ADMIN] could not create shared memory segment: Invalid argument
  • From: Scott Whitney
• Re: [ADMIN] could not create shared memory segment: Invalid argument
  • From: Ryan King - NOAA Affiliate
• Re: Query planner not using indexes with JOIN query and OR clause
  • From: Merlin Moncure
• Query planner not using indexes with JOIN query and OR clause
  • From: Ben Hoyt
• Re: Hmmm... why does CPU-intensive pl/pgsql code parallelise so badly when queries parallelise fine? Anyone else seen this?
  • From: James Cloos
• Re: QUERY PLANNER - Indexe mono column VS composite Index
  • From: Jeff Janes
• Re: QUERY PLANNER - Indexe mono column VS composite Index
  • From: Nicolas Paris
• Re: QUERY PLANNER - Indexe mono column VS composite Index
  • From: Guillaume Lelarge
• QUERY PLANNER - Indexe mono column VS composite Index
  • From: Nicolas Paris
• Re: pg_stat_all_indexes understand
  • From: Jeff Janes
• Re: Hmmm... why does CPU-intensive pl/pgsql code parallelise so badly when queries parallelise fine? Anyone else seen this?
  • From: Graeme B. Bell
• Re: [BUGS] BUG #13493: pl/pgsql doesn't scale with cpus (PG9.3, 9.4)
  • From: Graeme B. Bell
• Re: Hmmm... why does CPU-intensive pl/pgsql code parallelise so badly when queries parallelise fine? Anyone else seen this?
  • From: Merlin Moncure
• Re: Hmmm... why does pl/pgsql code parallelise so badly when queries parallelise fine? Anyone else seen this?
  • From: Graeme B. Bell
• Re: Hmmm... why does CPU-intensive pl/pgsql code parallelise so badly when queries parallelise fine? Anyone else seen this?
  • From: Graeme B. Bell
• Re: Hmmm... why does CPU-intensive pl/pgsql code parallelise so badly when queries parallelise fine? Anyone else seen this?
  • From: Graeme B. Bell
• Re: Hmmm... why does CPU-intensive pl/pgsql code parallelise so badly when queries parallelise fine? Anyone else seen this?
  • From: Thomas Kellerer
• Re: Hmmm... why does CPU-intensive pl/pgsql code parallelise so badly when queries parallelise fine? Anyone else seen this?
  • From: Merlin Moncure
• Re: Hmmm... why does CPU-intensive pl/pgsql code parallelise so badly when queries parallelise fine? Anyone else seen this?
  • From: Merlin Moncure
• pg_stat_all_indexes understand
  • From: Nicolas Paris
• Re: Hmmm... why does pl/pgsql code parallelise so badly when queries parallelise fine? Anyone else seen this?
  • From: Andres Freund
• Re: Hmmm... why does pl/pgsql code parallelise so badly when queries parallelise fine? Anyone else seen this?
  • From: Graeme B. Bell
• Re: Hmmm... why does CPU-intensive pl/pgsql code parallelise so badly when queries parallelise fine? Anyone else seen this?
  • From: Graeme B. Bell
• Re: Hmmm... why does CPU-intensive pl/pgsql code parallelise so badly when queries parallelise fine? Anyone else seen this?
  • From: Andres Freund
• Re: Hmmm... why does CPU-intensive pl/pgsql code parallelise so badly when queries parallelise fine? Anyone else seen this?
  • From: Graeme B. Bell
• Re: Hmmm... why does CPU-intensive pl/pgsql code parallelise so badly when queries parallelise fine? Anyone else seen this?
  • From: Tom Lane
• Re: Hmmm... why does CPU-intensive pl/pgsql code parallelise so badly when queries parallelise fine? Anyone else seen this?
  • From: Andres Freund
• Re: Hmmm... why does CPU-intensive pl/pgsql code parallelise so badly when queries parallelise fine? Anyone else seen this?
  • From: Craig James
• Re: Hmmm... why does CPU-intensive pl/pgsql code parallelise so badly when queries parallelise fine? Anyone else seen this?
  • From: Andres Freund
• Re: Hmmm... why does CPU-intensive pl/pgsql code parallelise so badly when queries parallelise fine? Anyone else seen this?
  • From: Merlin Moncure
• Re: Hmmm... why does CPU-intensive pl/pgsql code parallelise so badly when queries parallelise fine? Anyone else seen this?
  • From: Craig James
• Re: Hmmm... why does CPU-intensive pl/pgsql code parallelise so badly when queries parallelise fine? Anyone else seen this?
  • From: Joshua D. Drake
• Re: Hmmm... why does CPU-intensive pl/pgsql code parallelise so badly when queries parallelise fine? Anyone else seen this?
  • From: Craig James
• Re: Hmmm... why does pl/pgsql code parallelise so badly when queries parallelise fine? Anyone else seen this?
  • From: Andres Freund
• Re: Hmmm... why does pl/pgsql code parallelise so badly when queries parallelise fine? Anyone else seen this?
  • From: Graeme B. Bell
• Re: Hmmm... why does CPU-intensive pl/pgsql code parallelise so badly when queries parallelise fine? Anyone else seen this?
  • From: Graeme B. Bell
• Re: wildcard text filter switched to boolean column, performance is way worse
  • From: Marc Mamin
• Re: Hmmm... why does CPU-intensive pl/pgsql code parallelise so badly when queries parallelise fine? Anyone else seen this?
  • From: Joshua D. Drake
• Re: Hmmm... why does CPU-intensive pl/pgsql code parallelise so badly when queries parallelise fine? Anyone else seen this?
  • From: Craig James
• Hmmm... why does CPU-intensive pl/pgsql code parallelise so badly when queries parallelise fine? Anyone else seen this?
  • From: Graeme B. Bell
• Re: Hmmm... why does pl/pgsql code parallelise so badly when queries parallelise fine? Anyone else seen this?
  • From: Merlin Moncure
• Re: Hmmm... why does pl/pgsql code parallelise so badly when queries parallelise fine? Anyone else seen this?
  • From: Graeme B. Bell
• Re: New server: SSD/RAID recommendations?
  • From: Heikki Linnakangas
• Re: New server: SSD/RAID recommendations?
  • From: Graeme B. Bell
• Re: New server: SSD/RAID recommendations?
  • From: Heikki Linnakangas
• Re: New server: SSD/RAID recommendations?
  • From: Merlin Moncure
• Re: New server: SSD/RAID recommendations?
  • From: Wes Vaske (wvaske)
• Re: New server: SSD/RAID recommendations?
  • From: Graeme B. Bell
• Re: New server: SSD/RAID recommendations?
  • From: Scott Marlowe
• Re: New server: SSD/RAID recommendations?
  • From: Graeme B. Bell
• Re: New server: SSD/RAID recommendations?
  • From: Michael Nolan
• Re: New server: SSD/RAID recommendations?
  • From: Graeme B. Bell
• Re: Sudden connection and load average spikes with postgresql 9.3
  • From: Scott Marlowe
• Re: New server: SSD/RAID recommendations?
  • From: Karl Denninger
• Re: New server: SSD/RAID recommendations?
  • From: Graeme B. Bell
• Re: New server: SSD/RAID recommendations?
  • From: Wei Shan
• Re: New server: SSD/RAID recommendations?
  • From: Graeme B. Bell
• Re: New server: SSD/RAID recommendations?
  • From: Graeme B. Bell
• Re: New server: SSD/RAID recommendations?
  • From: Merlin Moncure
• Re: wildcard text filter switched to boolean column, performance is way worse
  • From: Mike Broers
• Re: New server: SSD/RAID recommendations?
  • From: Vitalii Tymchyshyn
• Re: wildcard text filter switched to boolean column, performance is way worse
  • From: Mike Broers
• Re: wildcard text filter switched to boolean column, performance is way worse
  • From: Tom Lane
• Re: New server: SSD/RAID recommendations?
  • From: Graeme B. Bell
• Re: New server: SSD/RAID recommendations?
  • From: Graeme B. Bell
• wildcard text filter switched to boolean column, performance is way worse
  • From: Mike Broers
• Re: New server: SSD/RAID recommendations?
  • From: Heikki Linnakangas
• Re: New server: SSD/RAID recommendations?
  • From: Wes Vaske (wvaske)
• Re: New server: SSD/RAID recommendations?
  • From: Graeme B. Bell
• Re: New server: SSD/RAID recommendations?
  • From: Merlin Moncure
• Re: New server: SSD/RAID recommendations?
  • From: Graeme B. Bell
• Re: New server: SSD/RAID recommendations?
  • From: Karl Denninger
• Re: New server: SSD/RAID recommendations?
  • From: Graeme B. Bell
• Re: New server: SSD/RAID recommendations?
  • From: Graeme B. Bell
• Re: Sudden connection and load average spikes with postgresql 9.3
  • From: eudald_v
• Re: New server: SSD/RAID recommendations?
  • From: Karl Denninger
• Re: New server: SSD/RAID recommendations?
  • From: Mkrtchyan, Tigran
• Re: New server: SSD/RAID recommendations?
  • From: Graeme B. Bell
• Re: New server: SSD/RAID recommendations?
  • From: Mkrtchyan, Tigran
• Re: New server: SSD/RAID recommendations?
  • From: Graeme B. Bell
• Re: 9.5alpha1 vs 9.4
  • From: Mkrtchyan, Tigran
• Re: New server: SSD/RAID recommendations?
  • From: Joshua D. Drake
• Re: New server: SSD/RAID recommendations?
  • From: Steve Crawford
• Re: 9.5alpha1 vs 9.4
  • From: Josh Berkus
• Re: Hmmm... why does pl/pgsql code parallelise so badly when queries parallelise fine? Anyone else seen this?
  • From: Merlin Moncure
• Re: 9.5alpha1 vs 9.4
  • From: Mkrtchyan, Tigran
• Re: pgbouncer issue
  • From: Greg Sabino Mullane
• Re: 9.5alpha1 vs 9.4
  • From: Tom Lane
• Re: 9.5alpha1 vs 9.4
  • From: Andres Freund
• Re: 9.5alpha1 vs 9.4
  • From: Mkrtchyan, Tigran
• 9.5alpha1 vs 9.4
  • From: Mkrtchyan, Tigran
• Re: Hmmm... why does pl/pgsql code parallelise so badly when queries parallelise fine? Anyone else seen this?
  • From: Marc Mamin
• Hmmm... why does pl/pgsql code parallelise so badly when queries parallelise fine? Anyone else seen this?
  • From: Graeme B. Bell
• Re: Sudden connection and load average spikes with postgresql 9.3
  • From: Scott Marlowe
• Re: Sudden connection and load average spikes with postgresql 9.3
  • From: Kevin Grittner
• Re: Sudden connection and load average spikes with postgresql 9.3
  • From: Josh Berkus
• Re: Sudden connection and load average spikes with postgresql 9.3
  • From: Josh Berkus
• Re: New server: SSD/RAID recommendations?
  • From: Wes Vaske (wvaske)
• Re: New server: SSD/RAID recommendations?
  • From: Craig James
• Re: New server: SSD/RAID recommendations?
  • From: Craig James
• Re: New server: SSD/RAID recommendations?
  • From: Craig James
• Re: Sudden connection and load average spikes with postgresql 9.3
  • From: eudald_v
• Re: New server: SSD/RAID recommendations?
  • From: Merlin Moncure
• Re: New server: SSD/RAID recommendations?
  • From: Wes Vaske (wvaske)
• Re: New server: SSD/RAID recommendations?
  • From: Scott Marlowe
• Re: New server: SSD/RAID recommendations?
  • From: Andreas Joseph Krogh
• New server: SSD/RAID recommendations?
  • From: Craig James
• Re: Sudden connection and load average spikes with postgresql 9.3
  • From: Josh Berkus
• Re: Sudden connection and load average spikes with postgresql 9.3
  • From: eudald_v
• Re: Sudden connection and load average spikes with postgresql 9.3
  • From: Tom Lane
• Sudden connection and load average spikes with postgresql 9.3
  • From: eudald_v
• Does anyone have python code which digests pgbench -r output?
  • From: Josh Berkus
• Re: Slow query (planner insisting on using 'external merge' sort type)
  • From: Mark Kirkwood
• pgbouncer issue
  • From: Sheena, Prabhjot
• Re: Slow query (planner insisting on using 'external merge' sort type)
  • From: Jim Nasby
• Re: Techniques to Avoid Temp Files
  • From: Jeff Janes
• Re: Slow query (planner insisting on using 'external merge' sort type)
  • From: Igor Neyman
• Re: Slow query (planner insisting on using 'external merge' sort type)
  • From: Igor Neyman
• Re: Slow query (planner insisting on using 'external merge' sort type)
  • From: Ian Pushee
• Re: Slow query (planner insisting on using 'external merge' sort type)
  • From: Ian Pushee
• Re: Slow query (planner insisting on using 'external merge' sort type)
  • From: Andreas Kretschmer
• Re: Slow query (planner insisting on using 'external merge' sort type)
  • From: Igor Neyman
• Slow query (planner insisting on using 'external merge' sort type)
  • From: Ian Pushee
• Re: Techniques to Avoid Temp Files
  • From: Albe Laurenz
• Re: PGBOUNCER ISSUE PLEASE HELP(Slowing down the site)
  • From: Sheena, Prabhjot
• Re: PGBOUNCER ISSUE PLEASE HELP(Slowing down the site)
  • From: ktm@xxxxxxxx
• Re: PGBOUNCER ISSUE PLEASE HELP(Slowing down the site)
  • From: Igor Neyman
• Re: How to calculate statistics for one column
  • From: Igor Neyman
• Re: PGBOUNCER ISSUE PLEASE HELP(Slowing down the site)
  • From: Jerry Sievers
• Techniques to Avoid Temp Files
  • From: Duane Murphy
• Re: PGBOUNCER ISSUE PLEASE HELP(Slowing down the site)
  • From: Sheena, Prabhjot
• Re: How to calculate statistics for one column
  • From: Irineu Ruiz
• Re: How to calculate statistics for one column
  • From: Igor Neyman
• Re: How to calculate statistics for one column
  • From: Irineu Ruiz
• Re: How to calculate statistics for one column
  • From: Igor Neyman
• Re: PGBOUNCER ISSUE PLEASE HELP(Slowing down the site)
  • From: ktm@xxxxxxxx
• How to calculate statistics for one column
  • From: Irineu Ruiz
• Re: PGBOUNCER ISSUE PLEASE HELP(Slowing down the site)
  • From: Sheena, Prabhjot
• Re: PGBOUNCER ISSUE PLEASE HELP(Slowing down the site)
  • From: Will Platnick
• Re: PGBOUNCER ISSUE PLEASE HELP(Slowing down the site)
  • From: ktm@xxxxxxxx
• PGBOUNCER ISSUE PLEASE HELP(Slowing down the site)
  • From: Sheena, Prabhjot
• Re: Do work_mem and shared buffers have 1g or 2g limit on 64 bit linux?
  • From: Tomas Vondra
• Re: Slow query: Postgres chooses nested loop over hash join, whery by hash join is much faster, wrong number of rows estimated
  • From: Merlin Moncure
• Re: Do work_mem and shared buffers have 1g or 2g limit on 64 bit linux?
  • From: Kaijiang Chen
• Re: Do work_mem and shared buffers have 1g or 2g limit on 64 bit linux?
  • From: Joe Conway
• Do work_mem and shared buffers have 1g or 2g limit on 64 bit linux?
  • From: Kaijiang Chen
• Re: Do work_mem and shared buffers have 1g or 2g limit on 64 bit linux?
  • From: Joshua D. Drake
• Re: pg bouncer issue what does sv_used column means
  • From: ktm@xxxxxxxx
• Re: pg bouncer issue what does sv_used column means
  • From: Andrew Dunstan
• Re: pg bouncer issue what does sv_used column means
  • From: Sheena, Prabhjot
• Re: Are there tuning parameters that don't take effect immediately?
  • From: Michael Nolan
• Re: Are there tuning parameters that don't take effect immediately?
  • From: Joshua D. Drake
• Re: Are there tuning parameters that don't take effect immediately?
  • From: David G. Johnston
• Are there tuning parameters that don't take effect immediately?
  • From: Michael Nolan
• Re: pg bouncer issue what does sv_used column means
  • From: Xenofon Papadopoulos
• pg bouncer issue what does sv_used column means
  • From: Sheena, Prabhjot
• Re: Slow query - lots of temporary files.
  • From: Johann Spies
• Slow query: Postgres chooses nested loop over hash join, whery by hash join is much faster, wrong number of rows estimated
  • From: Sasa Vilic
• Re: How to reduce writing on disk ? (90 gb on pgsql_tmp)
  • From: Claudio Freire
• Re: How to reduce writing on disk ? (90 gb on pgsql_tmp)
  • From: ben.play
• Re: Row estimates off by two orders of magnitude with hstore
  • From: Merlin Moncure
• Re: Row estimates off by two orders of magnitude with hstore
  • From: Patrick Krecker
• Re: Row estimates off by two orders of magnitude with hstore
  • From: Merlin Moncure
• Re: Row estimates off by two orders of magnitude with hstore
  • From: Patrick Krecker
• Re: Row estimates off by two orders of magnitude with hstore
  • From: Merlin Moncure
• Re: Row estimates off by two orders of magnitude with hstore
  • From: Josh Berkus
• Re: Row estimates off by two orders of magnitude with hstore
  • From: Merlin Moncure
• Row estimates off by two orders of magnitude with hstore
  • From: Patrick Krecker
• Re: Slow query - lots of temporary files.
  • From: Tomas Vondra
• Re: Slow query - lots of temporary files.
  • From: Johann Spies
• Re: Slow query - lots of temporary files.
  • From: Claudio Freire
• Slow query - lots of temporary files.
  • From: Johann Spies
• Re: How to reduce writing on disk ? (90 gb on pgsql_tmp)
  • From: Claudio Freire
• Re: How to reduce writing on disk ? (90 gb on pgsql_tmp)
  • From: ben.play
• Re: Query running slow for only one specific id. (Postgres 9.3) version
  • From: Matheus de Oliveira
• Re: Re: [GENERAL] Re: Query running slow for only one specific id. (Postgres 9.3) version
  • From: Steve Crawford
• Re: [GENERAL] Re: Query running slow for only one specific id. (Postgres 9.3) version
  • From: Steve Crawford
• Re: Query running slow for only one specific id. (Postgres 9.3) version
  • From: Igor Neyman
• Re: Query running slow for only one specific id. (Postgres 9.3) version
  • From: Sheena, Prabhjot
• Re: Query running slow for only one specific id. (Postgres 9.3) version
  • From: Steve Crawford
• Re: Query running slow for only one specific id. (Postgres 9.3) version
  • From: Igor Neyman
• Query running slow for only one specific id. (Postgres 9.3) version
  • From: Sheena, Prabhjot
• Re: How to reduce writing on disk ? (90 gb on pgsql_tmp)
  • From: Tomas Vondra
• Re: Need more IOPS? This should get you drooling... (5xnvme drives)
  • From: Graeme B. Bell
• Re: Need more IOPS? This should get you drooling... (5xnvme drives)
  • From: Dorian Hoxha
• Re: Need more IOPS? This should get you drooling... (5xnvme drives)
  • From: Graeme B. Bell
• Need more IOPS? This should get you drooling... (5xnvme drives)
  • From: Graeme B. Bell
• Re: How to reduce writing on disk ? (90 gb on pgsql_tmp)
  • From: Mark Kirkwood
• Re: How to reduce writing on disk ? (90 gb on pgsql_tmp)
  • From: Scott Marlowe
• Re: How to reduce writing on disk ? (90 gb on pgsql_tmp)
  • From: Scott Marlowe
• Re: How to reduce writing on disk ? (90 gb on pgsql_tmp)
  • From: Tomas Vondra
• Re: How to reduce writing on disk ? (90 gb on pgsql_tmp)
  • From: Yves Dorfsman
• Re: How to reduce writing on disk ? (90 gb on pgsql_tmp)
  • From: Joshua D. Drake
• Re: How to reduce writing on disk ? (90 gb on pgsql_tmp)
  • From: Tomas Vondra
• Re: How to reduce writing on disk ? (90 gb on pgsql_tmp)
  • From: Claudio Freire
• Re: How to reduce writing on disk ? (90 gb on pgsql_tmp)
  • From: Scott Marlowe
• Re: How to reduce writing on disk ? (90 gb on pgsql_tmp)
  • From: Tomas Vondra
• Re: How to reduce writing on disk ? (90 gb on pgsql_tmp)
  • From: Claudio Freire
• Re: How to reduce writing on disk ? (90 gb on pgsql_tmp)
  • From: Scott Marlowe
• Re: How to reduce writing on disk ? (90 gb on pgsql_tmp)
  • From: Tomas Vondra
• Re: How to reduce writing on disk ? (90 gb on pgsql_tmp)
  • From: ben.play
• Re: How to reduce writing on disk ? (90 gb on pgsql_tmp)
  • From: Tomas Vondra
• Re: How to reduce writing on disk ? (90 gb on pgsql_tmp)
  • From: chiru r
• Re: How to reduce writing on disk ? (90 gb on pgsql_tmp)
  • From: amulsul
• Re: How to reduce writing on disk ? (90 gb on pgsql_tmp)
  • From: David G. Johnston
• How to reduce writing on disk ? (90 gb on pgsql_tmp)
  • From: ben.play
• Re: Postgres is using 100% CPU
  • From: Ashik S L
• Re: Postgres is using 100% CPU
  • From: Graeme B. Bell
• Re: Postgres is using 100% CPU
  • From: Graeme B. Bell
• Re: Connection time when using SSL
  • From: Tomas Vondra
• Connection time when using SSL
  • From: Marco Di Cesare
• Re: Postgres is using 100% CPU
  • From: Scott Marlowe
• Re: Fastest way / best practice to calculate "next birthdays"
  • From: Kevin Grittner
• Re: Slow hash join performance with many batches
  • From: Tom Lane
• Slow hash join performance with many batches
  • From: Alex Adriaanse
• Re: Postgres is using 100% CPU
  • From: Merlin Moncure
• Re: Postgres is using 100% CPU
  • From: Ashik S L
• Re: Different plan for very similar queries
  • From: Tomas Vondra
• Re: Different plan for very similar queries
  • From: Tom Lane
• Re: Different plan for very similar queries
  • From: Tomas Vondra
• Re: Different plan for very similar queries
  • From: Tom Lane
• Re: Postgres is using 100% CPU
  • From: Yves Dorfsman
• Re: Postgres is using 100% CPU
  • From: Jean-David Beyer
• Re: Different plan for very similar queries
  • From: Peter J. Holzer
• Re: Postmaster eating up all my cpu
  • From: Tomas Vondra
• Postmaster eating up all my cpu
  • From: birimblongas
• Re: Different plan for very similar queries
  • From: Tom Lane
• Re: Postgres is using 100% CPU
  • From: Tomas Vondra
• Re: Postgres is using 100% CPU
  • From: Ashik S L
• Re: Different plan for very similar queries
  • From: Tomas Vondra
• Re: Postgres is using 100% CPU
  • From: Tomas Vondra
• Re: Postgres is using 100% CPU
  • From: Yves Dorfsman
• Postgres is using 100% CPU
  • From: Ashik S L
• Fwd: Postgres is using 100% CPU
  • From: Ashik S L
• Re: Different plan for very similar queries
  • From: Peter J. Holzer
• Different plan for very similar queries
  • From: Peter J. Holzer
• Re: Partitioning and performance
  • From: Jim Nasby
• Re: Fastest Backup & Restore for perf testing
  • From: Jim Nasby
• Re: Partitioning and performance
  • From: Ravi Krishna
• Partitioning and performance
  • From: Ravi Krishna
• Re: ERROR: missing chunk number 0 for toast value 1821556134 in pg_toast_17881
  • From: Josh Berkus
• Re: Fastest Backup & Restore for perf testing
  • From: Steve Atkins
• Re: Fastest Backup & Restore for perf testing
  • From: Andrew Dunstan
• Fastest Backup & Restore for perf testing
  • From: Wes Vaske (wvaske)
• ERROR: missing chunk number 0 for toast value 1821556134 in pg_toast_17881
  • From: Tory M Blue
• Re: MAX() and multi-column index on a partitioned table?
  • From: Tom Lane
• Re: MAX() and multi-column index on a partitioned table?
  • From: Dave Johansen
• Re: MAX() and multi-column index on a partitioned table?
  • From: Tom Lane
• MAX() and multi-column index on a partitioned table?
  • From: Dave Johansen
• Re: Fastest way / best practice to calculate "next birthdays"
  • From: Jim Nasby
• Re: How to clean/truncate / VACUUM FULL pg_largeobject without (much) downtime?
  • From: Jim Nasby
• Re: PostgreSQL disk fragmentation causes performance problems on Windows
  • From: Josh Berkus
• Re: PostgreSQL disk fragmentation causes performance problems on Windows
  • From: Vitalii Tymchyshyn
• Re: PostgreSQL disk fragmentation causes performance problems on Windows
  • From: Andres Freund
• Re: PostgreSQL disk fragmentation causes performance problems on Windows
  • From: Josh Berkus
• Re: Fastest way / best practice to calculate "next birthdays"
  • From: David G. Johnston
• Re: Fastest way / best practice to calculate "next birthdays"
  • From: Bosco Rama
• Re: union all and filter / index scan -> seq scan
  • From: Tom Lane
• Re: union all and filter / index scan -> seq scan
  • From: Vitalii Tymchyshyn
• union all and filter / index scan -> seq scan
  • From: Florian Lohoff
• Re: Fastest way / best practice to calculate "next birthdays"
  • From: David G. Johnston
• Re: Fastest way / best practice to calculate "next birthdays"
  • From: er.tejaspatel88@xxxxxxxxx
• How to clean/truncate / VACUUM FULL pg_largeobject without (much) downtime?
  • From: Muthusamy, Sivaraman
• Re: optimization join on random value
  • From: Heikki Linnakangas
• optimization join on random value
  • From: Anton Bushmelev
• Re: Index Scan Backward Slow
  • From: Robert Klemme
• Re: Index Scan Backward Slow
  • From: David Osborne
• Re: Index Scan Backward Slow
  • From: Evgeniy Shishkin
• Index Scan Backward Slow
  • From: David Osborne
• Re: PostgreSQL disk fragmentation causes performance problems on Windows
  • From: Andrew Dunstan
• Re: PostgreSQL disk fragmentation causes performance problems on Windows
  • From: ktm@xxxxxxxx
• Re: PostgreSQL disk fragmentation causes performance problems on Windows
  • From: Joshua D. Drake
• Re: PostgreSQL disk fragmentation causes performance problems on Windows
  • From: Andres Freund
• Re: PostgreSQL disk fragmentation causes performance problems on Windows
  • From: Andres Freund
• PostgreSQL disk fragmentation causes performance problems on Windows
  • From: Jan Gunnar Dyrset
• Re: Query plan with missing timespans
  • From: Kyotaro HORIGUCHI
• Re: Postgresql Host Swapping Hard With Abundant Free Memory
  • From: Jim Nasby
• Postgresql Host Swapping Hard With Abundant Free Memory
  • From: Christian Gough
• Re: Query plan with missing timespans
  • From: Jason Petersen
• Re: Query plan with missing timespans
  • From: Andomar
• Re: Query plan with missing timespans
  • From: Kevin Grittner
• Query plan with missing timespans
  • From: Andomar
• Re: extract(year from date) doesn't use index but maybe could?
  • From: Jim Nasby
• Re: extract(year from date) doesn't use index but maybe could?
  • From: Gavin Flower
• Re: extract(year from date) doesn't use index but maybe could?
  • From: Tom Lane
• Re: extract(year from date) doesn't use index but maybe could?
  • From: Yves Dorfsman
• Re: extract(year from date) doesn't use index but maybe could?
  • From: Tom Lane
• Re: extract(year from date) doesn't use index but maybe could?
  • From: Tomas Vondra
• Re: extract(year from date) doesn't use index but maybe could?
  • From: Adam Tauno Williams
• Re: extract(year from date) doesn't use index but maybe could?
  • From: Jon Dufresne
• Re: extract(year from date) doesn't use index but maybe could?
  • From: Tomas Vondra
• extract(year from date) doesn't use index but maybe could?
  • From: Jon Dufresne
• Performance of vacuumlo
  • From: Andreas Joseph Krogh
• Re: unlogged tables
  • From: Jim Nasby
• Re: Some performance testing?
  • From: Josh Berkus
• Re: unlogged tables
  • From: Jeff Janes
• Re: unlogged tables
  • From: Jeff Janes
• Re: unlogged tables
  • From: dgabriel
• Re: unlogged tables
  • From: Yves Dorfsman