Postgres Performance Date Index

• Thread Index

• CREATE INDEX uses INDEX ?
  • From: Nicolas Paris
• Re: EXPLAIN (no ANALYZE) taking an hour for INSERT FROM SELECT
  • From: Jeff Janes
• Re: EXPLAIN (no ANALYZE) taking an hour for INSERT FROM SELECT
  • From: Tom Lane
• Re: EXPLAIN (no ANALYZE) taking an hour for INSERT FROM SELECT
  • From: Kevin Grittner
• Re: PG 9.3 materialized view VS Views, indexes, shared memory
  • From: Nicolas Paris
• Re: EXPLAIN (no ANALYZE) taking an hour for INSERT FROM SELECT
  • From: Tom Lane
• Re: EXPLAIN (no ANALYZE) taking an hour for INSERT FROM SELECT
  • From: Jeff Janes
• Re: EXPLAIN (no ANALYZE) taking an hour for INSERT FROM SELECT
  • From: Tomas Vondra
• Re: slow server : s_lock and _bt_checkkeys on perf top
  • From: Soni M
• Re: slow server : s_lock and _bt_checkkeys on perf top
  • From: Merlin Moncure
• Re: PG 9.3 materialized view VS Views, indexes, shared memory
  • From: Nicolas Paris
• Re: PG 9.3 materialized view VS Views, indexes, shared memory
  • From: Jim Nasby
• Re: PG 9.3 materialized view VS Views, indexes, shared memory
  • From: Nicolas Paris
• Re: PG 9.3 materialized view VS Views, indexes, shared memory
  • From: Jim Nasby
• Re: slow server : s_lock and _bt_checkkeys on perf top
  • From: Jim Nasby
• Re: EXPLAIN (no ANALYZE) taking an hour for INSERT FROM SELECT
  • From: Tom Lane
• Re: EXPLAIN (no ANALYZE) taking an hour for INSERT FROM SELECT
  • From: Tomas Vondra
• Re: EXPLAIN (no ANALYZE) taking an hour for INSERT FROM SELECT
  • From: Marc Mamin
• Re: EXPLAIN (no ANALYZE) taking an hour for INSERT FROM SELECT
  • From: Vladimir Sitnikov
• Re: EXPLAIN (no ANALYZE) taking an hour for INSERT FROM SELECT
  • From: Gunnlaugur Thor Briem
• Re: Reverse Key Index
  • From: Sven R. Kunze
• Re: EXPLAIN (no ANALYZE) taking an hour for INSERT FROM SELECT
  • From: Marc Mamin
• slow server : s_lock and _bt_checkkeys on perf top
  • From: Soni M
• EXPLAIN (no ANALYZE) taking an hour for INSERT FROM SELECT
  • From: Gunnlaugur Thor Briem
• Re: pushing order by + limit to union subqueries
  • From: Tom Lane
• pushing order by + limit to union subqueries
  • From: Paolo Losi
• Bad cost estimate with FALSE filter condition
  • From: Josh Berkus
• Re: Reverse Key Index
  • From: Sven R. Kunze
• Re: Reverse Key Index
  • From: Thomas Kellerer
• Re: Reverse Key Index
  • From: Heikki Linnakangas
• Re: Reverse Key Index
  • From: Sven R. Kunze
• Re: Reverse Key Index
  • From: Thomas Kellerer
• Re: Reverse Key Index
  • From: Sven R. Kunze
• Re: Reverse Key Index
  • From: Josh Berkus
• Re: Regarding "Point-in-time Recovery" feature
  • From: luis . sa
• Re: Regarding "Point-in-time Recovery" feature
  • From: Mathis, Jason
• Regarding "Point-in-time Recovery" feature
  • From: Saurabh Gupta A
• Re: PG 9.3 materialized view VS Views, indexes, shared memory
  • From: Nicolas Paris
• Re: PG 9.3 materialized view VS Views, indexes, shared memory
  • From: Nicolas Paris
• Re: PG 9.3 materialized view VS Views, indexes, shared memory
  • From: Matheus de Oliveira
• Re: PG 9.3 materialized view VS Views, indexes, shared memory
  • From: Nicolas Paris
• Re: PG 9.3 materialized view VS Views, indexes, shared memory
  • From: Matheus de Oliveira
• PG 9.3 materialized view VS Views, indexes, shared memory
  • From: Nicolas Paris
• Re: Configuration tips for very large database
  • From: Nico Sabbi
• Re: Reverse Key Index
  • From: Sven R. Kunze
• Re: Reverse Key Index
  • From: Tom Lane
• Reverse Key Index
  • From: Sven R. Kunze
• Re: Configuration tips for very large database
  • From: Graeme B. Bell
• Re: Configuration tips for very large database
  • From: ktm@xxxxxxxx
• Re: Yet another abort-early plan disaster on 9.3
  • From: Michael Paquier
• Re: query - laziness of lateral join with function
  • From: Paul Callaghan
• Re: Configuration tips for very large database
  • From: Claudio Freire
• Re: Configuration tips for very large database
  • From: Mathis, Jason
• Re: Survey: Max TPS you've ever seen
  • From: Mark Kirkwood
• Re: Configuration tips for very large database
  • From: Kevin Grittner
• Re: Configuration tips for very large database
  • From: Nico Sabbi
• Re: Configuration tips for very large database
  • From: Kevin Grittner
• Configuration tips for very large database
  • From: Nico Sabbi
• Re: query - laziness of lateral join with function
  • From: David G Johnston
• Re: query - laziness of lateral join with function
  • From: Tom Lane
• query - laziness of lateral join with function
  • From: paulcc
• Re: Survey: Max TPS you've ever seen
  • From: Graeme B. Bell
• Re: Survey: Max TPS you've ever seen
  • From: Gudmundsson Martin (mg)
• Re: Survey: Max TPS you've ever seen
  • From: Luis Antonio Dias de Sá Junior
• Re: slow query
  • From: Tom Lane
• Re: slow query
  • From: Torsten Förtsch
• slow query
  • From: Sathish Nelson
• slow nested views in 9.3
  • From: Pascal Depuis
• Re: Survey: Max TPS you've ever seen
  • From: Mark Kirkwood
• Re: Survey: Max TPS you've ever seen
  • From: Graeme B. Bell
• Re: Survey: Max TPS you've ever seen
  • From: Luis Antonio Dias de Sá Junior
• Re: [ADMIN] <empty string> Vs NULL
  • From: Florent Guillaume
• Re: [ADMIN] <empty string> Vs NULL
  • From: sridhar bamandlapally
• Re: Poor performance when deleting from entity-attribute-value type master-table
  • From: Josh Berkus
• Re: Poor performance when deleting from entity-attribute-value type master-table
  • From: Andreas Joseph Krogh
• Re: Poor performance when deleting from entity-attribute-value type master-table
  • From: Jerry Sievers
• Re: Poor performance when deleting from entity-attribute-value type master-table
  • From: Igor Neyman
• Re: Survey: Max TPS you've ever seen
  • From: Gavin Flower
• Poor performance when deleting from entity-attribute-value type master-table
  • From: Andreas Joseph Krogh
• Re: Avoiding Refreezing XIDs Repeatedly
  • From: Tom Lane
• Survey: Max TPS you've ever seen
  • From: Luis Antonio Dias de Sá Junior
• Re: Avoiding Refreezing XIDs Repeatedly
  • From: Alvaro Herrera
• Re: Avoiding Refreezing XIDs Repeatedly
  • From: bkrug
• Re: Avoiding Refreezing XIDs Repeatedly
  • From: Matheus de Oliveira
• Re: Avoiding Refreezing XIDs Repeatedly
  • From: Alvaro Herrera
• Re: Avoiding Refreezing XIDs Repeatedly
  • From: bkrug
• Re: Migrating a FoxPro system and would like input on the best way to achieve optimal performance
  • From: David G Johnston
• Re: Avoiding Refreezing XIDs Repeatedly
  • From: Alvaro Herrera
• Re: Avoiding Refreezing XIDs Repeatedly
  • From: Matheus de Oliveira
• Avoiding Refreezing XIDs Repeatedly
  • From: bkrug
• Migrating a FoxPro system and would like input on the best way to achieve optimal performance
  • From: TonyS
• Re: [ADMIN] <empty string> Vs NULL
  • From: Geoff Winkless
• Re: [ADMIN] <empty string> Vs NULL
  • From: Geoff Winkless
• Re: [ADMIN] <empty string> Vs NULL
  • From: Marc Mamin
• Re: <empty string> Vs NULL
  • From: Nikolas Everett
• Re: [ADMIN] <empty string> Vs NULL
  • From: Pavel Stehule
• [ADMIN] <empty string> Vs NULL
  • From: sridhar bamandlapally
• Re: Copy command Faster than original select
  • From: Belal Al-Hamed
• Re: Copy command Faster than original select
  • From: Tom Lane
• Re: Copy command Faster than original select
  • From: Igor Neyman
• Re: Copy command Faster than original select
  • From: Matheus de Oliveira
• Re: Copy command Faster than original select
  • From: Pavel Stehule
• Re: Copy command Faster than original select
  • From: Belal Al-Hamed
• Re: Copy command Faster than original select
  • From: Matheus de Oliveira
• Re: Copy command Faster than original select
  • From: Belal Al-Hamed
• Re: Copy command Faster than original select
  • From: Matheus de Oliveira
• Re: Copy command Faster than original select
  • From: Pavel Stehule
• Re: Copy command Faster than original select
  • From: Belal Al-Hamed
• Re: Copy command Faster than original select
  • From: Pavel Stehule
• Re: Copy command Faster than original select
  • From: Belal Al-Hamed
• Re: Copy command Faster than original select
  • From: Pavel Stehule
• Re: Copy command Faster than original select
  • From: Belal Al-Hamed
• Re: Copy command Faster than original select
  • From: Pavel Stehule
• Copy command Faster than original select
  • From: belal
• Re: working around JSONB's lack of stats?
  • From: Josh Berkus
• Re: why pg_class.relfrozenxid needs to be updated for frozen tables (where all rows have xmin=2)?
  • From: Jim Nasby
• Re: why pg_class.relfrozenxid needs to be updated for frozen tables (where all rows have xmin=2)?
  • From: Slava Mudry
• Re: why pg_class.relfrozenxid needs to be updated for frozen tables (where all rows have xmin=2)?
  • From: Jim Nasby
• Re: working around JSONB's lack of stats?
  • From: Jim Nasby
• Re: why pg_class.relfrozenxid needs to be updated for frozen tables (where all rows have xmin=2)?
  • From: Jim Nasby
• Re: working around JSONB's lack of stats?
  • From: Merlin Moncure
• Re: Why is GIN index slowing down my query?
  • From: Marc Mamin
• Re: Why is GIN index slowing down my query?
  • From: Marc Mamin
• Re: Unexpected (bad) performance when querying indexed JSONB column
  • From: Christian Weyer
• Re: Why is GIN index slowing down my query?
  • From: Tom Lane
• Re: Why is GIN index slowing down my query?
  • From: AlexK987
• Re: Why is GIN index slowing down my query?
  • From: AlexK987
• Re: Why is GIN index slowing down my query?
  • From: Tom Lane
• Why is GIN index slowing down my query?
  • From: AlexK987
• Re: Unexpected (bad) performance when querying indexed JSONB column
  • From: Tom Lane
• Re: Unexpected (bad) performance when querying indexed JSONB column
  • From: Christian Weyer
• Re: working around JSONB's lack of stats?
  • From: Josh Berkus
• Re: Unexpected (bad) performance when querying indexed JSONB column
  • From: Josh Berkus
• Re: Unexpected (bad) performance when querying indexed JSONB column
  • From: Christian Weyer
• Unexpected (bad) performance when querying indexed JSONB column
  • From: Christian Weyer
• Re: Query performance
  • From: Pavel Stehule
• Re: Performance of Postgresql Foreign Data Wrapper
  • From: Jim Nasby
• Re: Autocompletion with full text search
  • From: Jim Nasby
• Re: Query performance
  • From: Jim Nasby
• Re: working around JSONB's lack of stats?
  • From: Jim Nasby
• Re: why pg_class.relfrozenxid needs to be updated for frozen tables (where all rows have xmin=2)?
  • From: Jim Nasby
• why pg_class.relfrozenxid needs to be updated for frozen tables (where all rows have xmin=2)?
  • From: Slava Mudry
• Re: working around JSONB's lack of stats?
  • From: Josh Berkus
• Re: working around JSONB's lack of stats?
  • From: Tomas Vondra
• Re: working around JSONB's lack of stats?
  • From: Peter Geoghegan
• Re: working around JSONB's lack of stats?
  • From: Josh Berkus
• Re: working around JSONB's lack of stats?
  • From: Peter Geoghegan
• Re: working around JSONB's lack of stats?
  • From: Josh Berkus
• Re: working around JSONB's lack of stats?
  • From: Tomas Vondra
• Re: Why is PostgreSQL not using my index?
  • From: Merlin Moncure
• working around JSONB's lack of stats?
  • From: Josh Berkus
• Re: Why is PostgreSQL not using my index?
  • From: Tomas Vondra
• Re: Why is PostgreSQL not using my index?
  • From: Tom Lane
• Re: How to tell ANALYZE to collect statistics from the whole table?
  • From: Jeff Janes
• Why is PostgreSQL not using my index?
  • From: Christian Roche
• Re: Query performance
  • From: Marc Mamin
• Re: Query performance
  • From: Tomas Vondra
• Re: Query performance
  • From: Pavel Stehule
• Re: Query performance
  • From: Joe Van Dyk
• Re: Query performance
  • From: Pavel Stehule
• Re: Query performance
  • From: Joe Van Dyk
• Re: Query performance
  • From: Pavel Stehule
• Re: Query performance
  • From: Joe Van Dyk
• Re: Query performance
  • From: Joe Van Dyk
• Query performance
  • From: Joe Van Dyk
• Re: How to tell ANALYZE to collect statistics from the whole table?
  • From: Tom Lane
• Re: Initial insert
  • From: Tomas Vondra
• Re: How to tell ANALYZE to collect statistics from the whole table?
  • From: Tomas Vondra
• Re: How to tell ANALYZE to collect statistics from the whole table?
  • From: AlexK987
• Re: How to tell ANALYZE to collect statistics from the whole table?
  • From: Tomas Vondra
• How to tell ANALYZE to collect statistics from the whole table?
  • From: AlexK987
• Re: Initial insert
  • From: Laurent Cathala
• Initial insert
  • From: Laurent Cathala
• Re: shared_buffers vs Linux file cache
  • From: Roman Konoval
• Re: Strange choice of general index over partial index
  • From: Josh Berkus
• Re: Strange choice of general index over partial index
  • From: Mark Kirkwood
• Re: shared_buffers vs Linux file cache
  • From: Huan Ruan
• Re: Strange choice of general index over partial index
  • From: Josh Berkus
• Re: Strange choice of general index over partial index
  • From: Mark Kirkwood
• Re: Strange choice of general index over partial index
  • From: Mark Kirkwood
• Re: Strange choice of general index over partial index
  • From: Tom Lane
• Re: Strange choice of general index over partial index
  • From: Mark Kirkwood
• Re: Strange choice of general index over partial index
  • From: Tom Lane
• Autocompletion with full text search
  • From: Ivan Schneider
• Re: Strange choice of general index over partial index
  • From: Mark Kirkwood
• Re: Strange choice of general index over partial index
  • From: Jeff Janes
• Re: shared_buffers vs Linux file cache
  • From: Tom Lane
• Strange choice of general index over partial index
  • From: Josh Berkus
• Re: shared_buffers vs Linux file cache
  • From: Jeff Janes
• Re: shared_buffers vs Linux file cache
  • From: Glyn Astill
• shared_buffers vs Linux file cache
  • From: Huan Ruan
• Performance of Postgresql Foreign Data Wrapper
  • From: Cassiano, Marco
• Re: New server optimization advice
  • From: Merlin Moncure
• Re: New server optimization advice
  • From: Claudio Freire
• New server optimization advice
  • From: Steve Crawford
• Re: Excessive memory used for INSERT
  • From: Alessandro Ipe
• Re: trying to run pgbench-tools postgresql ubuntu ERROR: relation "branches" does not exist
  • From: cesar
• Re: trying to run pgbench-tools postgresql ubuntu ERROR: relation "branches" does not exist
  • From: Michael Paquier
• trying to run pgbench-tools postgresql ubuntu ERROR: relation "branches" does not exist
  • From: cesar
• Re: Excessive memory used for INSERT
  • From: Tom Lane
• Re: Excessive memory used for INSERT
  • From: Alessandro Ipe
• Re: Number of Columns and Update
  • From: Andrew Dunstan
• Re: Number of Columns and Update
  • From: Heikki Linnakangas
• Number of Columns and Update
  • From: Robert DiFalco
• Re: Question about trigram GIST index
  • From: Kevin Grittner
• [GENERAL] Postgresql 9.2, Memoy cache usage.
  • From: Cristian Iturrieta
• Re: Question about trigram GIST index
  • From: Robert DiFalco
• Re: Question about trigram GIST index
  • From: Jeff Janes
• Re: Question about trigram GIST index
  • From: Robert DiFalco
• Re: Question about trigram GIST index
  • From: Giuseppe Broccolo
• Re: Question about trigram GIST index
  • From: Robert DiFalco
• Re: Excessive memory used for INSERT
  • From: Alessandro Ipe
• Re: Question about trigram GIST index
  • From: Tom Lane
• Question about trigram GIST index
  • From: Robert DiFalco
• Re: Excessive memory used for INSERT
  • From: Tom Lane
• Re: Excessive memory used for INSERT
  • From: Alessandro Ipe
• Re: Excessive memory used for INSERT
  • From: Alessandro Ipe
• Re: Excessive memory used for INSERT
  • From: Alessandro Ipe
• Re: Excessive memory used for INSERT
  • From: Torsten Förtsch
• Re: Excessive memory used for INSERT
  • From: Tom Lane
• Re: Excessive memory used for INSERT
  • From: Alessandro Ipe
• Re: Excessive memory used for INSERT
  • From: Alessandro Ipe
• Re: Excessive memory used for INSERT
  • From: Tom Lane
• Re: Excessive memory used for INSERT
  • From: Torsten Zuehlsdorff
• Excessive memory used for INSERT
  • From: Alessandro Ipe
• Re: Yet another abort-early plan disaster on 9.3
  • From: Simon Riggs
• Re: 8xIntel S3500 SSD in RAID10 on Dell H710p
  • From: Strahinja Kustudić
• Re: Tuning the configuration
  • From: Evgeniy Shishkin
• Re: Tuning the configuration
  • From: Graeme B. Bell
• Re: 8xIntel S3500 SSD in RAID10 on Dell H710p
  • From: Graeme B. Bell
• Re: Postgres slave not catching up (on 9.2)
  • From: Ruben Domingo Gaspar Aparicio
• Re: Tuning the configuration
  • From: Graeme B. Bell
• Re: Postgres slave not catching up (on 9.2)
  • From: Ruben Domingo Gaspar Aparicio
• Re: Re: [SQL] querying with index on jsonb slower than standard column. Why?
  • From: Claudio Freire
• Re: Re: [SQL] querying with index on jsonb slower than standard column. Why?
  • From: Andrew Dunstan
• Re: Re: [SQL] querying with index on jsonb slower than standard column. Why?
  • From: Tom Lane
• Re: Re: [SQL] querying with index on jsonb slower than standard column. Why?
  • From: Andrew Dunstan
• Re: Re: [SQL] querying with index on jsonb slower than standard column. Why?
  • From: Claudio Freire
• Re: Re: [SQL] querying with index on jsonb slower than standard column. Why?
  • From: Tom Lane
• Re: Re: [SQL] querying with index on jsonb slower than standard column. Why?
  • From: Josh Berkus
• Re: 8xIntel S3500 SSD in RAID10 on Dell H710p
  • From: Merlin Moncure
• Re: Yet another abort-early plan disaster on 9.3
  • From: Simon Riggs
• Re: Yet another abort-early plan disaster on 9.3
  • From: Simon Riggs
• Re: Tuning the configuration
  • From: Mark Kirkwood
• Re: Tuning the configuration
  • From: Eric Pierce
• Re: Tuning the configuration
  • From: Andrea Suisani
• Re: Tuning the configuration
  • From: Andrea Suisani
• Re: Tuning the configuration
  • From: Maila Fatticcioni
• Re: Tuning the configuration
  • From: Evgeniy Shishkin
• Re: Tuning the configuration
  • From: Andrea Suisani
• Re: Tuning the configuration
  • From: Maila Fatticcioni
• Re: 8xIntel S3500 SSD in RAID10 on Dell H710p
  • From: Mark Kirkwood
• Re: Tuning the configuration
  • From: Patrick Krecker
• Re: intel s3500 -- hot stuff
  • From: Jeff Janes
• Re: When does PostgreSQL collapse subqueries to join?
  • From: Tom Lane
• When does PostgreSQL collapse subqueries to join?
  • From: Sven R. Kunze
• Tuning the configuration
  • From: Maila Fatticcioni
• Re: 8xIntel S3500 SSD in RAID10 on Dell H710p
  • From: Strahinja Kustudić
• Re: 8xIntel S3500 SSD in RAID10 on Dell H710p
  • From: Mark Kirkwood
• Re: Yet another abort-early plan disaster on 9.3
  • From: Simon Riggs
• Re: Yet another abort-early plan disaster on 9.3
  • From: Josh Berkus
• 8xIntel S3500 SSD in RAID10 on Dell H710p
  • From: Strahinja Kustudić
• Re: intel s3500 -- hot stuff
  • From: Bruce Momjian
• Re: Hardware Requirements
  • From: Claudio Freire
• Hardware Requirements
  • From: Vivekanand Joshi
• Re: intel s3500 -- hot stuff
  • From: Merlin Moncure
• Re: [SQL] querying with index on jsonb slower than standard column. Why?
  • From: Tim Dudgeon
• Re: [SQL] querying with index on jsonb slower than standard column. Why?
  • From: Adrian Klaver
• Re: [SQL] querying with index on jsonb slower than standard column. Why?
  • From: Tom Lane
• Re: [SQL] querying with index on jsonb slower than standard column. Why?
  • From: Adrian Klaver
• Re: [SQL] querying with index on jsonb slower than standard column. Why?
  • From: Tom Lane
• Re: intel s3500 -- hot stuff
  • From: Bruce Momjian
• Re: Query doesn't use index on hstore column
  • From: Michael Barker
• Re: Yet another abort-early plan disaster on 9.3
  • From: Simon Riggs
• Re: Yet another abort-early plan disaster on 9.3
  • From: Merlin Moncure
• Re: Yet another abort-early plan disaster on 9.3
  • From: Simon Riggs
• Re: Query doesn't use index on hstore column
  • From: Tom Lane
• Re: Query doesn't use index on hstore column
  • From: ktm@xxxxxxxx
• Query doesn't use index on hstore column
  • From: Michael Barker
• Re: issue in postgresql 9.1.3 in using arrow key in Solaris platform
  • From: Josh Berkus
• Re: CTE query plan ignores selective index
  • From: Tom Lane
• CTE query plan ignores selective index
  • From: Patrick Krecker
• Re: Postgres slave not catching up (on 9.2)
  • From: Ruben Domingo Gaspar Aparicio
• Re: Small performance regression in 9.2 has a big impact
  • From: Scott Marlowe
• Re: [GENERAL] issue in postgresql 9.1.3 in using arrow key in Solaris platform
  • From: Adrian Klaver
• Re: pgtune + configurations with 9.3
  • From: Johann Spies
• Re: pgtune + configurations with 9.3
  • From: Johann Spies
• issue in postgresql 9.1.3 in using arrow key in Solaris platform
  • From: M Tarkeshwar Rao
• Re: Small performance regression in 9.2 has a big impact
  • From: Tom Lane
• Re: Small performance regression in 9.2 has a big impact
  • From: Tom Lane
• Re: Small performance regression in 9.2 has a big impact
  • From: Tom Lane
• Re: Small performance regression in 9.2 has a big impact
  • From: Scott Marlowe
• Re: Small performance regression in 9.2 has a big impact
  • From: Tom Lane
• Re: Small performance regression in 9.2 has a big impact
  • From: Heikki Linnakangas
• Small performance regression in 9.2 has a big impact
  • From: Scott Marlowe
• Re: Why don't use index on x when ORDER BY x, y?
  • From: Tom Lane
• Re: Why don't use index on x when ORDER BY x, y?
  • From: Robert Klemme
• Why don't use index on x when ORDER BY x, y?
  • From: Vlad Arkhipov
• Re: pgtune + configurations with 9.3
  • From: Johann Spies
• Re: Yet another abort-early plan disaster on 9.3
  • From: Tomas Vondra
• Re: Yet another abort-early plan disaster on 9.3
  • From: Jeff Janes
• Re: A pessimistic planner
  • From: Tom Lane
• A pessimistic planner
  • From: Stuart Bishop
• Re: Plan uses wrong index, preferring to scan pkey index instead
  • From: Yuri Kunde Schlesner
• Re: Partitions and work_mem?
  • From: Dave Johansen
• Re: Partitions and work_mem?
  • From: Tom Lane
• Re: Partitions and work_mem?
  • From: Magnus Hagander
• Re: pgtune + configurations with 9.3
  • From: Stuart Bishop
• Re: Re[2]: [PERFORM] pgtune + configurations with 9.3
  • From: Stuart Bishop
• Re: Partitions and work_mem?
  • From: Dave Johansen
• Re: Plan uses wrong index, preferring to scan pkey index instead
  • From: Tom Lane
• Re: Plan uses wrong index, preferring to scan pkey index instead
  • From: Yuri Kunde Schlesner
• Plan uses wrong index, preferring to scan pkey index instead
  • From: Yuri Kunde Schlesner
• Re: pgtune + configurations with 9.3
  • From: Mark Kirkwood
• Re: Index order ignored after `is null` in query
  • From: Jim Nasby
• Re: pgtune + configurations with 9.3
  • From: Jim Nasby
• Re: updating statistics on slow running query
  • From: Jim Nasby
• Re: pgtune + configurations with 9.3
  • From: Mark Kirkwood
• Re[2]: [PERFORM] pgtune + configurations with 9.3
  • From: Alexey Vasiliev
• Re: pgtune + configurations with 9.3
  • From: Shaun Thomas
• [PERFORM] pgtune + configurations with 9.3
  • From: Alexey Vasiliev
• Re: pgtune + configurations with 9.3
  • From: Shaun Thomas
• Re: 9.0 performance degradation with kernel 3.11
  • From: Glyn Astill
• Re[2]: [PERFORM] pgtune + configurations with 9.3
  • From: Alexey Vasiliev
• Re: Increased shared_buffer setting = lower hit ratio ?
  • From: Jeff Janes
• Re: Increased shared_buffer setting = lower hit ratio ?
  • From: Tomas Vondra
• Re: Increased shared_buffer setting = lower hit ratio ?
  • From: CS DBA
• Increased shared_buffer setting = lower hit ratio ?
  • From: CS DBA
• 9.0 performance degradation with kernel 3.11
  • From: Filip Rembiałkowski
• Re: Lock pileup causes server to stall
  • From: Jesper Krogh
• Re: Lock pileup causes server to stall
  • From: Josh Berkus
• Re: Lock pileup causes server to stall
  • From: Alvaro Herrera
• Re: Lock pileup causes server to stall
  • From: Jesper Krogh
• Re: Lock pileup causes server to stall
  • From: Jeff Janes
• Re: Lock pileup causes server to stall
  • From: Josh Berkus
• Re: [GENERAL] trigger Before or After
  • From: Adrian Klaver
• Re: [GENERAL] trigger Before or After
  • From: Albe Laurenz
• trigger Before or After
  • From: avpro avpro
• Re: Performance bug in prepared statement binding in 9.2?
  • From: Josh Berkus
• Re: updating statistics on slow running query
  • From: Eric Ramirez
• Re: Lock pileup causes server to stall
  • From: Alvaro Herrera
• Re: Performance bug in prepared statement binding in 9.2?
  • From: Jeff Janes
• Lock pileup causes server to stall
  • From: Josh Berkus
• Re: Performance bug in prepared statement binding in 9.2?
  • From: Josh Berkus
• Re: Performance bug in prepared statement binding in 9.2?
  • From: Tom Lane
• Re: Performance bug in prepared statement binding in 9.2?
  • From: Andres Freund
• Re: Performance bug in prepared statement binding in 9.2?
  • From: Josh Berkus
• Re: Performance bug in prepared statement binding in 9.2?
  • From: Jeff Janes
• Re: updating statistics on slow running query
  • From: desmodemone
• Re: 9.3 performance issues, lots of bind and parse log entries
  • From: Josh Berkus
• Re: Performance bug in prepared statement binding in 9.2?
  • From: Josh Berkus
• updating statistics on slow running query
  • From: Eric Ramirez
• Re: Postgres slave not catching up (on 9.2)
  • From: Ruben Domingo Gaspar Aparicio
• Re: Postgres slave not catching up (on 9.2)
  • From: Andres Freund
• Re: Postgres slave not catching up (on 9.2)
  • From: Robert Klemme
• Postgres slave not catching up (on 9.2)
  • From: Ruben Domingo Gaspar Aparicio
• Re: Postgres does not use indexes with OR-conditions
  • From: David G Johnston
• Re: Postgres does not use indexes with OR-conditions
  • From: Tom Lane
• Re: Postgres does not use indexes with OR-conditions
  • From: Kevin Grittner
• Re: pgtune + configurations with 9.3
  • From: Shaun Thomas
• Re: Postgres does not use indexes with OR-conditions
  • From: Andrew Dunstan
• Re: Index order ignored after `is null` in query
  • From: Artūras Lapinskas
• Re: Postgres does not use indexes with OR-conditions
  • From: Vlad Arkhipov
• Re: Postgres does not use indexes with OR-conditions
  • From: David Rowley
• Postgres does not use indexes with OR-conditions
  • From: arhipov
• Re: pgtune + configurations with 9.3
  • From: Josh Berkus
• Re: Index order ignored after `is null` in query
  • From: Tom Lane
• Re: Index order ignored after `is null` in query
  • From: Artūras Lapinskas
• Re: log_temp_files (integer), tuning work_mem
  • From: Guillaume Lelarge
• Index order ignored after `is null` in query
  • From: Artūras Lapinskas
• Re: 9.3 performance issues, lots of bind and parse log entries
  • From: Tomas Vondra
• Index order ignored after `is null` in query
  • From: Artūras Lapinskas
• log_temp_files (integer), tuning work_mem
  • From: Tory M Blue
• Re: 9.3 performance issues, lots of bind and parse log entries
  • From: Tory M Blue
• Re: intel s3500 -- hot stuff
  • From: Merlin Moncure
• intel s3500 -- hot stuff
  • From: Merlin Moncure
• Re: 9.3 performance issues, lots of bind and parse log entries
  • From: Tomas Vondra
• Re: 9.3 performance issues, lots of bind and parse log entries
  • From: Tory M Blue
• Re: Incredibly slow restore times after 9.0>9.2 upgrade
  • From: jmcdonagh
• 9.3 performance issues, lots of bind and parse log entries
  • From: Tory M Blue
• Re: Incredibly slow restore times after 9.0>9.2 upgrade
  • From: jmcdonagh
• Re: unnecessary sort in the execution plan when doing group by
  • From: Simon Riggs
• Re: Replication Lag Causes
  • From: Stuart Bishop
• Re: assignment vs SELECT INTO
  • From: Andrew Dunstan
• Re: assignment vs SELECT INTO
  • From: Matheus de Oliveira
• Re: assignment vs SELECT INTO
  • From: Tom Lane
• assignment vs SELECT INTO
  • From: Andrew Dunstan
• Re: Replication Lag Causes
  • From: Felipe Santos
• Re: Replication Lag Causes
  • From: Mike Wilson
• Re: Replication Lag Causes
  • From: Mike Wilson
• Re: Replication Lag Causes
  • From: Valentine Gogichashvili
• Replication Lag Causes
  • From: Mike Wilson
• Re: pgtune + configurations with 9.3
  • From: Albe Laurenz
• Re: Incredibly slow restore times after 9.0>9.2 upgrade
  • From: Tomas Vondra
• Re: Incredibly slow restore times after 9.0>9.2 upgrade
  • From: Jerry Sievers
• Re: Incredibly slow restore times after 9.0>9.2 upgrade
  • From: jmcdonagh
• pgtune + configurations with 9.3
  • From: Tory M Blue
• Re: Incredibly slow restore times after 9.0>9.2 upgrade
  • From: jmcdonagh
• Re: Incredibly slow restore times after 9.0>9.2 upgrade
  • From: Mathis, Jason
• Re: Incredibly slow restore times after 9.0>9.2 upgrade
  • From: jmcdonagh
• Re: Sanity checking big select performance
  • From: Kevin Grittner
• Re: unnecessary sort in the execution plan when doing group by
  • From: Huang, Suya
• Re: Sanity checking big select performance
  • From: Tomas Vondra
• Re: Incredibly slow restore times after 9.0>9.2 upgrade
  • From: Tomas Vondra
• Sanity checking big select performance
  • From: Jeff Chen
• Incredibly slow restore times after 9.0>9.2 upgrade
  • From: jmcdonagh
• Re: unnecessary sort in the execution plan when doing group by
  • From: David Rowley
• unnecessary sort in the execution plan when doing group by
  • From: Huang, Suya
• Re: extremly bad select performance on huge table
  • From: Björn Wittich
• Checkpoints tuning
  • From: pinker
• Re: extremly bad select performance on huge table
  • From: Björn Wittich
• Re: extremly bad select performance on huge table
  • From: Kevin Grittner
• Re: extremly bad select performance on huge table
  • From: Igor Neyman
• Re: Query with large number of joins
  • From: Merlin Moncure
• Re: IS NOT NULL and LEFT JOIN
  • From: Laurent Martelli
• Re: ERROR: out of memory | with 23GB cached 7GB reserved on 30GB machine
  • From: Montana Low
• Re: extremly bad select performance on huge table
  • From: Björn Wittich
• Re: ERROR: out of memory | with 23GB cached 7GB reserved on 30GB machine
  • From: Montana Low
• Re: ERROR: out of memory | with 23GB cached 7GB reserved on 30GB machine
  • From: Tomas Vondra
• Re: ERROR: out of memory | with 23GB cached 7GB reserved on 30GB machine
  • From: Tom Lane
• ERROR: out of memory | with 23GB cached 7GB reserved on 30GB machine
  • From: Montana Low
• Re: Query with large number of joins
  • From: Igor Neyman
• Re: Query with large number of joins
  • From: Marco Di Cesare
• Re: Query with large number of joins
  • From: Marco Di Cesare
• Re: extremly bad select performance on huge table
  • From: Igor Neyman
• Re: extremly bad select performance on huge table
  • From: Björn Wittich
• Re: extremly bad select performance on huge table
  • From: Tom Lane
• Re: extremly bad select performance on huge table
  • From: Igor Neyman
• Re: extremly bad select performance on huge table
  • From: Björn Wittich
• extremly bad select performance on huge table
  • From: Björn Wittich
• Re: Query with large number of joins
  • From: Tom Lane
• Re: Query with large number of joins
  • From: Tom Lane
• Re: Query with large number of joins
  • From: Andrew Dunstan
• Re: Query with large number of joins
  • From: Marco Di Cesare
• Re: Query with large number of joins
  • From: Merlin Moncure
• Re: Query Performance Problem
  • From: Felipe Santos
• Query Performance Problem
  • From: john
• Re: Query with large number of joins
  • From: Felipe Santos
• Re: IS NOT NULL and LEFT JOIN
  • From: David Rowley
• Re: Query with large number of joins
  • From: Tom Lane
• Re: IS NOT NULL and LEFT JOIN
  • From: David G Johnston
• Re: IS NOT NULL and LEFT JOIN
  • From: David G Johnston
• Re: IS NOT NULL and LEFT JOIN
  • From: Laurent Martelli
• Query with large number of joins
  • From: Marco Di Cesare
• Re: IS NOT NULL and LEFT JOIN
  • From: Tom Lane
• Re: IS NOT NULL and LEFT JOIN
  • From: Laurent Martelli
• Re: Yet another abort-early plan disaster on 9.3
  • From: Greg Stark
• Re: IS NOT NULL and LEFT JOIN
  • From: David Rowley
• IS NOT NULL and LEFT JOIN
  • From: Laurent Martelli
• Re: Yet another abort-early plan disaster on 9.3
  • From: Tomas Vondra
• Re: Yet another abort-early plan disaster on 9.3
  • From: Greg Stark
• 9.4 performance improvements test
  • From: Josh Berkus
• CopyManager(In/out) vs. delete/insert directly
  • From: Emi Lu
• Re: Partitioned tables and SELECT ... ORDER BY ... LIMIT
  • From: Дмитрий Шалашов
• Re: Partitioned tables and SELECT ... ORDER BY ... LIMIT
  • From: Felipe Santos
• Re: Partitioned tables and SELECT ... ORDER BY ... LIMIT
  • From: Jeff Janes
• Re: Partitioned tables and SELECT ... ORDER BY ... LIMIT
  • From: Дмитрий Шалашов
• Re: Partitioned tables and SELECT ... ORDER BY ... LIMIT
  • From: François Beausoleil
• Partitioned tables and SELECT ... ORDER BY ... LIMIT
  • From: Дмитрий Шалашов
• Re: Partitions and work_mem?
  • From: Tom Lane
• Re: Partitions and work_mem?
  • From: Josh Berkus
• Re: Partitions and work_mem?
  • From: Igor Neyman
• Re: Partitions and work_mem?
  • From: Dave Johansen
• Re: Partitions and work_mem?
  • From: Igor Neyman
• Re: Partitions and work_mem?
  • From: Dave Johansen
• Re: Partitions and work_mem?
  • From: Igor Neyman
• Re: Partitions and work_mem?
  • From: Dave Johansen
• Re: Yet another abort-early plan disaster on 9.3
  • From: Tomas Vondra
• Re: Yet another abort-early plan disaster on 9.3
  • From: Josh Berkus
• Re: Partitions and work_mem?
  • From: Josh Berkus
• Re: Partitions and work_mem?
  • From: Jeff Janes
• Partitions and work_mem?
  • From: Dave Johansen
• Re: Yet another abort-early plan disaster on 9.3
  • From: Tomas Vondra
• Re: Yet another abort-early plan disaster on 9.3
  • From: Craig James
• Re: Yet another abort-early plan disaster on 9.3
  • From: Tomas Vondra
• Re: Yet another abort-early plan disaster on 9.3
  • From: Tomas Vondra
• Re: Yet another abort-early plan disaster on 9.3
  • From: Craig James
• Re: Yet another abort-early plan disaster on 9.3
  • From: Tomas Vondra
• Re: Yet another abort-early plan disaster on 9.3
  • From: Greg Stark
• Re: char(N), varchar(N), varchar, text
  • From: Emi Lu
• Re: char(N), varchar(N), varchar, text
  • From: Andrew Dunstan
• char(N), varchar(N), varchar, text
  • From: Emi Lu
• Re: query plan question, nested loop vs hash join
  • From: Andrey Lizenko
• Re: Performance degradation in 324577f39bc8738ed0ec24c36c5cb2c2f81ec660
  • From: Vladimir Kamarzin
• Bad optimization/planning on Postgres window-based queries (partition by(, group by?)) - 1000x speedup
  • From: and
• Re: help: function failing
  • From: Andrew Dunstan
• Re: help: function failing
  • From: Sergey Konoplev
• Re: query plan question, nested loop vs hash join
  • From: Marti Raudsepp
• Re: pg_basebackup - odd performance
  • From: Mike Blackwell
• query plan question, nested loop vs hash join
  • From: Andrey Lizenko
• help: function failing
  • From: George Neuner
• Re: Performance degradation in 324577f39bc8738ed0ec24c36c5cb2c2f81ec660
  • From: Tom Lane
• Performance degradation in 324577f39bc8738ed0ec24c36c5cb2c2f81ec660
  • From: Vladimir Kamarzin
• Re: pg_basebackup - odd performance
  • From: Jov
• Re: <idle> issue?
  • From: jaime soler
• pg_basebackup - odd performance
  • From: Mike Blackwell
• Re: <idle> issue?
  • From: Felipe Santos
• <idle> issue?
  • From: Emi Lu
• Re: query plan question, nested loop vs hash join
  • From: Andrey Lizenko
• Re: query plan question, nested loop vs hash join
  • From: Andrey Lizenko
• Re: query plan question, nested loop vs hash join
  • From: Tom Lane
• Re: query plan question, nested loop vs hash join
  • From: Victor Yegorov
• query plan question, nested loop vs hash join
  • From: Andrey Lizenko
• Re: auto vaccum is dying
  • From: Jeff Janes
• Re: auto vaccum is dying
  • From: Rodrigo Barboza
• Re: auto vaccum is dying
  • From: Rodrigo Barboza
• Re: Yet another abort-early plan disaster on 9.3
  • From: Tomas Vondra
• Re: Yet another abort-early plan disaster on 9.3
  • From: Tomas Vondra
• Re: Yet another abort-early plan disaster on 9.3
  • From: Jeff Janes
• Re: Planning for Scalability
  • From: Claudio Freire
• Re: Planning for Scalability
  • From: Graeme B. Bell
• Re: Planning for Scalability
  • From: Roberto Grandi
• Re: Planning for Scalability
  • From: ktm@xxxxxxxx
• Planning for Scalability
  • From: Roberto Grandi
• Re: performance of SELECT * much faster than SELECT <colname> with large offset
  • From: Marti Raudsepp
• Re: performance of SELECT * much faster than SELECT <colname> with large offset
  • From: Tom Lane
• performance of SELECT * much faster than SELECT <colname> with large offset
  • From: Marc Slemko
• Re: Yet another abort-early plan disaster on 9.3
  • From: Peter Geoghegan
• Re: Yet another abort-early plan disaster on 9.3
  • From: Josh Berkus
• Re: auto vaccum is dying
  • From: Jeff Janes
• Re: Yet another abort-early plan disaster on 9.3
  • From: Ryan Johnson
• Re: Yet another abort-early plan disaster on 9.3
  • From: Peter Geoghegan
• Re: Yet another abort-early plan disaster on 9.3
  • From: Simon Riggs
• Re: auto vaccum is dying
  • From: Dorian Hoxha
• Re: auto vaccum is dying
  • From: Heikki Linnakangas
• auto vaccum is dying
  • From: Rodrigo Barboza
• Re: Yet another abort-early plan disaster on 9.3
  • From: Josh Berkus
• Re: Yet another abort-early plan disaster on 9.3
  • From: Simon Riggs
• Re: Yet another abort-early plan disaster on 9.3
  • From: Merlin Moncure
• Re: Yet another abort-early plan disaster on 9.3
  • From: Gavin Flower
• Re: Yet another abort-early plan disaster on 9.3
  • From: Graeme B. Bell
• Re: Yet another abort-early plan disaster on 9.3
  • From: Jeff Janes
• Re: Yet another abort-early plan disaster on 9.3
  • From: Jeff Janes
• Re: Yet another abort-early plan disaster on 9.3
  • From: Tom Lane
• Re: Yet another abort-early plan disaster on 9.3
  • From: Claudio Freire
• Re: Yet another abort-early plan disaster on 9.3
  • From: Graeme B. Bell
• Re: Yet another abort-early plan disaster on 9.3
  • From: Simon Riggs
• Re: Yet another abort-early plan disaster on 9.3
  • From: Simon Riggs
• Re: Yet another abort-early plan disaster on 9.3
  • From: Greg Stark
• Re: Very slow postgreSQL 9.3.4 query
  • From: Burgess, Freddie
• Re: Yet another abort-early plan disaster on 9.3
  • From: Gavin Flower
• Re: Yet another abort-early plan disaster on 9.3
  • From: Tom Lane
• Re: Yet another abort-early plan disaster on 9.3
  • From: Josh Berkus
• Re: Yet another abort-early plan disaster on 9.3
  • From: Simon Riggs
• Re: Very slow postgreSQL 9.3.4 query
  • From: Graeme B. Bell
• Re: Yet another abort-early plan disaster on 9.3
  • From: Merlin Moncure
• Re: after upgrade 8.4->9.3 query is slow not using index scan
  • From: Matúš Svrček
• Re: Very slow postgreSQL 9.3.4 query
  • From: Burgess, Freddie
• Re: Very slow postgreSQL 9.3.4 query
  • From: Burgess, Freddie
• Re: after upgrade 8.4->9.3 query is slow not using index scan
  • From: Victor Yegorov
• Re: Very slow postgreSQL 9.3.4 query
  • From: Burgess, Freddie
• Re: Very slow postgreSQL 9.3.4 query
  • From: Graeme B. Bell
• after upgrade 8.4->9.3 query is slow not using index scan
  • From: Matúš Svrček
• Very slow postgreSQL 9.3.4 query
  • From: Burgess, Freddie
• Re: Yet another abort-early plan disaster on 9.3
  • From: Simon Riggs
• Re: postgres 9.3 vs. 9.4
  • From: Mark Kirkwood
• Re: postgres 9.3 vs. 9.4
  • From: Imre Samu
• Re: Which update action quicker?
  • From: Emi Lu
• Re: Which update action quicker?
  • From: Heikki Linnakangas
• Re: postgres 9.3 vs. 9.4
  • From: Mkrtchyan, Tigran
• Re: postgres 9.3 vs. 9.4
  • From: Mark Kirkwood
• Re: postgres 9.3 vs. 9.4
  • From: Mkrtchyan, Tigran
• Which update action quicker?
  • From: Emi Lu
• Re: postgres 9.3 vs. 9.4
  • From: Merlin Moncure
• Re: Slow query
  • From: David G Johnston
• Re: postgres 9.3 vs. 9.4
  • From: Mkrtchyan, Tigran
• Slow query
  • From: Ross Elliott
• Re: Yet another abort-early plan disaster on 9.3
  • From: Josh Berkus
• Re: Yet another abort-early plan disaster on 9.3
  • From: Merlin Moncure
• Re: postgres 9.3 vs. 9.4
  • From: Merlin Moncure
• Re: Yet another abort-early plan disaster on 9.3
  • From: Josh Berkus
• Re: Yet another abort-early plan disaster on 9.3
  • From: Tom Lane
• Re: Yet another abort-early plan disaster on 9.3
  • From: Claudio Freire
• Re: query a table with lots of coulmns
  • From: Björn Wittich
• Re: query a table with lots of coulmns
  • From: Marc Mamin
• Re: query a table with lots of coulmns
  • From: Björn Wittich
• Re: Yet another abort-early plan disaster on 9.3
  • From: Greg Stark
• Re: postgres 9.3 vs. 9.4
  • From: Mark Kirkwood
• Re: query a table with lots of coulmns
  • From: Josh Berkus
• Re: Yet another abort-early plan disaster on 9.3
  • From: Josh Berkus
• Re: Yet another abort-early plan disaster on 9.3
  • From: Merlin Moncure
• Re: query a table with lots of coulmns
  • From: Pavel Stehule
• Re: query a table with lots of coulmns
  • From: Björn Wittich
• Re: query a table with lots of coulmns
  • From: Szymon Guz
• query a table with lots of coulmns
  • From: Björn Wittich
• Re: postgres 9.3 vs. 9.4
  • From: Mark Kirkwood
• Re: postgres 9.3 vs. 9.4
  • From: Mkrtchyan, Tigran
• Re: postgres 9.3 vs. 9.4
  • From: Mark Kirkwood
• Re: postgres 9.3 vs. 9.4
  • From: Mkrtchyan, Tigran
• Re: postgres 9.3 vs. 9.4
  • From: Mark Kirkwood
• Re: postgres 9.3 vs. 9.4
  • From: Mark Kirkwood
• Re: postgres 9.3 vs. 9.4
  • From: Jeff Janes
• Re: postgres 9.3 vs. 9.4
  • From: didier
• Re: postgres 9.3 vs. 9.4
  • From: Mkrtchyan, Tigran
• Re: postgres 9.3 vs. 9.4
  • From: Mkrtchyan, Tigran
• Re: postgres 9.3 vs. 9.4
  • From: Mark Kirkwood
• Re: postgres 9.3 vs. 9.4
  • From: Merlin Moncure
• Re: postgres 9.3 vs. 9.4
  • From: Mkrtchyan, Tigran
• Re: postgres 9.3 vs. 9.4
  • From: Andrew Dunstan
• Re: postgres 9.3 vs. 9.4
  • From: Mkrtchyan, Tigran
• Re: postgres 9.3 vs. 9.4
  • From: Josh Berkus
• Re: postgres 9.3 vs. 9.4
  • From: Mkrtchyan, Tigran
• Re: postgres 9.3 vs. 9.4
  • From: Jeff Janes
• Re: postgres 9.3 vs. 9.4
  • From: Mkrtchyan, Tigran
• Re: postgres 9.3 vs. 9.4
  • From: Mark Kirkwood
• postgres 9.3 vs. 9.4
  • From: Mkrtchyan, Tigran
• Re: Aggregating tsqueries
  • From: Heikki Linnakangas
• Aggregating tsqueries
  • From: Alexander Hill
• Yet another abort-early plan disaster on 9.3
  • From: Josh Berkus
• Re: Postgres Replaying WAL slowly
  • From: Simon Riggs
• How to interpret view pg_stat_bgwriter
  • From: Huang, Suya
• Re: Strange performance problem with query
  • From: Van Der Berg, Stefan
• Re: Strange performance problem with query
  • From: Kevin Grittner
• Strange performance problem with query
  • From: Van Der Berg, Stefan
• Re: weird execution plan
  • From: Huang, Suya
• Re: weird execution plan
  • From: David G Johnston
• Re: weird execution plan
  • From: Huang, Suya
• Re: how to change the provoke table in hash join
  • From: Huang, Suya
• Re: weird execution plan
  • From: David G Johnston
• weird execution plan
  • From: Huang, Suya
• Re: how to change the provoke table in hash join
  • From: Jeff Janes
• Re: how to change the provoke table in hash join
  • From: Matheus de Oliveira
• how to change the provoke table in hash join
  • From: Huang, Suya
• Re: query performance with hstore vs. non-hstore
  • From: Huang, Suya
• Re: Performance issue: index not used on GROUP BY...
  • From: gmb
• Re: why after increase the hash table partitions, tpmc decrease
  • From: Takashi Horikawa
• Implementing a functionality for processing heavy insertion
  • From: Shadin A
• why after increase the hash table partitions, tpmc decrease
  • From: Xiaoyulei
• Re: query performance with hstore vs. non-hstore
  • From: David G Johnston
• Re: query performance with hstore vs. non-hstore
  • From: Huang, Suya
• Re: query performance with hstore vs. non-hstore
  • From: Pavel Stehule
• Re: query performance with hstore vs. non-hstore
  • From: Huang, Suya
• Re: query performance with hstore vs. non-hstore
  • From: Pavel Stehule
• query performance with hstore vs. non-hstore
  • From: Huang, Suya
• Re: Very slow running query PostgreSQL 9.3.4
  • From: Victor Yegorov
• Very slow running query PostgreSQL 9.3.4
  • From: Burgess, Freddie
• Re: Performance issue: index not used on GROUP BY...
  • From: Josh Berkus
• Re: autocommit (true/false) for more than 1 million records
  • From: Emi Lu
• Re: Performance issue: index not used on GROUP BY...
  • From: Victor Yegorov
• Re: Performance issue: index not used on GROUP BY...
  • From: gmb
• Re: Performance issue: index not used on GROUP BY...
  • From: Marti Raudsepp
• Re: Performance issue: index not used on GROUP BY...
  • From: Victor Yegorov
• Re: Performance issue: index not used on GROUP BY...
  • From: gmb
• Re: Performance issue: index not used on GROUP BY...
  • From: Victor Yegorov
• Performance issue: index not used on GROUP BY...
  • From: gmb
• Re: autocommit (true/false) for more than 1 million records
  • From: Kevin Grittner
• Re: autocommit (true/false) for more than 1 million records
  • From: Albe Laurenz
• Re: autocommit (true/false) for more than 1 million records
  • From: Felipe Santos
• Re: autocommit (true/false) for more than 1 million records
  • From: Albe Laurenz
• Re: autocommit (true/false) for more than 1 million records
  • From: David Johnston
• Re: autocommit (true/false) for more than 1 million records
  • From: Alex Goncharov
• Re: Turn off Hyperthreading! WAS: 60 core performance with 9.3
  • From: Mark Kirkwood
• Re: autocommit (true/false) for more than 1 million records
  • From: David G Johnston
• Re: autocommit (true/false) for more than 1 million records
  • From: Alex Goncharov
• Re: autocommit (true/false) for more than 1 million records
  • From: Kevin Grittner
• Re: autocommit (true/false) for more than 1 million records
  • From: Alex Goncharov
• Re: tuning postgresql 9.3.5 and multiple cores
  • From: Mark Kirkwood
• Re: tuning postgresql 9.3.5 and multiple cores
  • From: Soni M
• Re: Turn off Hyperthreading! WAS: 60 core performance with 9.3
  • From: Mark Kirkwood
• Re: tuning postgresql 9.3.5 and multiple cores
  • From: Jeff Janes
• Re: Turn off Hyperthreading! WAS: 60 core performance with 9.3
  • From: Josh Berkus
• tuning postgresql 9.3.5 and multiple cores
  • From: Jeison Bedoya Delgado
• Re: autocommit (true/false) for more than 1 million records
  • From: Jeff Janes
• Re: autocommit (true/false) for more than 1 million records
  • From: Felipe Santos
• Re: autocommit (true/false) for more than 1 million records
  • From: David Johnston
• Re: autocommit (true/false) for more than 1 million records
  • From: Emi Lu