Postgres Performance Date Index

• Thread Index

• Re: [OT] Re: How much ram is too much
  • From: Joshua D. Drake
• Re: Please help me understand these numbers
  • From: Chris Hoover
• Re: How much ram is too much
  • From: Joshua D. Drake
• [OT] Re: How much ram is too much
  • From: Zoltan Boszormenyi
• Re: Please help me understand these numbers
  • From: Bill Moran
• Re: How much ram is too much
  • From: david
• Re: How much ram is too much
  • From: Dave Cramer
• Re: Please help me understand these numbers
  • From: Chris Hoover
• Re: dbt2 NOTPM numbers
  • From: Mark Wong
• Re: How much ram is too much
  • From: Ben
• Re: Best way to delete unreferenced rows?
  • From: Tyrrill, Ed
• Re: How much ram is too much
  • From: Guy Rouillier
• How much ram is too much
  • From: Dave Cramer
• Re: Please help me understand these numbers
  • From: Bill Moran
• Please help me understand these numbers
  • From: Chris Hoover
• Re: [ADMIN] reclaiming disk space after major updates
  • From: Andrew Sullivan
• Re: [ADMIN] reclaiming disk space after major updates
  • From: Dan Harris
• Re: VERY slow queries at random
  • From: Kristo Kaiv
• Database size
  • From: choksi
• Re: Getting Slow
  • From: Alvaro Herrera
• Re: Getting Slow
  • From: Tom Lane
• Re: performance drop on 8.2.4, reverting to 8.1.4
  • From: Tom Lane
• Re: performance drop on 8.2.4, reverting to 8.1.4
  • From: Alvaro Herrera
• Re: performance drop on 8.2.4, reverting to 8.1.4
  • From: Tom Lane
• Re: Weird 8.2.4 performance
  • From: Joshua D. Drake
• Re: Weird 8.2.4 performance
  • From: Mark Kirkwood
• Re: Best way to delete unreferenced rows?
  • From: Craig James
• Best way to delete unreferenced rows?
  • From: Tyrrill, Ed
• Re: VERY slow queries at random
  • From: Greg Smith
• Re: Getting Slow
  • From: Greg Smith
• Re: Getting Slow
  • From: Alvaro Herrera
• Re: Getting Slow
  • From: Steinar H. Gunderson
• Re: Getting Slow
  • From: Andrew Sullivan
• Getting Slow
  • From: Joe Lester
• Re: performance drop on 8.2.4, reverting to 8.1.4
  • From: Steven Flatt
• How Are The Variables Related?
  • From: Y Sidhu
• Re: VERY slow queries at random
  • From: Alvaro Herrera
• Re: VERY slow queries at random
  • From: Andrew Sullivan
• Re: VERY slow queries at random
  • From: Gunther Mayer
• Re: VERY slow queries at random
  • From: Gunther Mayer
• Re: VERY slow queries at random
  • From: Gunther Mayer
• Re: {Spam} Re: Weird 8.2.4 performance
  • From: Dimitri Fontaine
• Re: Weird 8.2.4 performance
  • From: Tom Lane
• Re: Weird 8.2.4 performance
  • From: Steinar H. Gunderson
• Re: Weird 8.2.4 performance
  • From: Kurt Overberg
• Re: Weird 8.2.4 performance
  • From: Mark Kirkwood
• Re: Weird 8.2.4 performance
  • From: Steinar H. Gunderson
• copy from performance on large tables with indexes
  • From: Marc Mamin
• Re: Weird 8.2.4 performance
  • From: Steinar H. Gunderson
• Re: Weird 8.2.4 performance
  • From: Richard Huxton
• Re: VERY slow queries at random
  • From: Kristo Kaiv
• Re: Thousands of tables versus on table?
  • From: david
• Re: LIKE search and performance
  • From: mark
• Re: Weird 8.2.4 performance
  • From: Michael Glaesemann
• Re: Weird 8.2.4 performance
  • From: Mark Kirkwood
• Weird 8.2.4 performance
  • From: Kurt Overberg
• Re: LIKE search and performance
  • From: James Mansion
• Re: Is this true?
  • From: Jeff Davis
• Re: VERY slow queries at random
  • From: Scott Marlowe
• Is this true?
  • From: Chris Hoover
• Re: Thousands of tables versus on table?
  • From: Jonah H. Harris
• Re: Thousands of tables versus on table?
  • From: Craig James
• Re: control of benchmarks (was: Thousands of tables)
  • From: Jonah H. Harris
• Re: VERY slow queries at random
  • From: Andrew Sullivan
• control of benchmarks (was: Thousands of tables)
  • From: Andrew Sullivan
• Re: Thousands of tables versus on table?
  • From: Jonah H. Harris
• Re: Thousands of tables versus on table?
  • From: Andrew Sullivan
• VERY slow queries at random
  • From: Gunther Mayer
• Re: Thousands of tables versus on table?
  • From: Andrew Sullivan
• Re: Thousands of tables versus on table?
  • From: Jonah H. Harris
• Re: Thousands of tables versus on table?
  • From: Jonah H. Harris
• Re: Thousands of tables versus on table?
  • From: Craig James
• Re: Thousands of tables versus on table?
  • From: Scott Marlowe
• Re: Thousands of tables versus on table?
  • From: Craig James
• Re: Thousands of tables versus on table?
  • From: Scott Marlowe
• Re: Thousands of tables versus on table?
  • From: Scott Marlowe
• Re: weird query plan
  • From: Tom Lane
• Re: upgraded to pgsql 8.2.4, getting worse performance then 7.4.x
  • From: Douglas J Hunley
• Re: different query plan because different limit # (Re: weird query plan)
  • From: Gregory Stark
• Re: different query plan because different limit # (Re: weird query plan)
  • From: weiping
• Re: Thousands of tables versus on table?
  • From: Heikki Linnakangas
• different query plan because different limit # (Re: weird query plan)
  • From: weiping
• Re: weird query plan
  • From: weiping
• weird query plan
  • From: weiping
• Re: Thousands of tables versus on table?
  • From: david
• Re: Thousands of tables versus on table?
  • From: david
• Re: performance drop on 8.2.4, reverting to 8.1.4
  • From: Tom Lane
• Re: Thousands of tables versus on table?
  • From: Steinar H. Gunderson
• Re: Thousands of tables versus on table?
  • From: Tom Lane
• Re: performance drop on 8.2.4, reverting to 8.1.4
  • From: Steinar H. Gunderson
• Re: performance drop on 8.2.4, reverting to 8.1.4
  • From: Steven Flatt
• Re: Thousands of tables versus on table?
  • From: david
• Re: Append table
  • From: Chander Ganesan
• Re: Thousands of tables versus on table?
  • From: Scott Marlowe
• Re: Thousands of tables versus on table?
  • From: Gregory Stark
• Re: Thousands of tables versus on table?
  • From: Scott Marlowe
• Re: Thousands of tables versus on table?
  • From: Thomas Andrews
• Re: upgraded to pgsql 8.2.4, getting worse performance then 7.4.x
  • From: Hanu Kurubar
• Re: Thousands of tables versus on table?
  • From: Scott Marlowe
• Re: dbt2 NOTPM numbers
  • From: Greg Smith
• Re: upgraded to pgsql 8.2.4, getting worse performance then 7.4.x
  • From: Douglas J Hunley
• Re: dbt2 NOTPM numbers
  • From: Markus Schiltknecht
• Re: upgraded to pgsql 8.2.4, getting worse performance then 7.4.x
  • From: Douglas J Hunley
• Re: dbt2 NOTPM numbers
  • From: Heikki Linnakangas
• Re: dbt2 NOTPM numbers
  • From: Markus Schiltknecht
• Re: Performance Problem
  • From: Gregory Stark
• Re: Performance Problem
  • From: Steinar H. Gunderson
• Performance Problem
  • From: Gauri Kanekar
• Performance Problem
  • From: Gauri Kanekar
• Re: Question about SQL performance
  • From: Richard Huxton
• Re: Question about SQL performance
  • From: mark
• Re: Question about SQL performance
  • From: PFC
• Question about SQL performance
  • From: Jason Lustig
• postgresql running on a virtual cluster
  • From: Dave Cramer
• Re: PostgreSQL not fully utilizing system resources?
  • From: Greg Smith
• Re: PostgreSQL not fully utilizing system resources?
  • From: Bill Moran
• Re: Thousands of tables versus on table?
  • From: david
• Re: upgraded to pgsql 8.2.4, getting worse performance then 7.4.x
  • From: Heikki Linnakangas
• Re: upgraded to pgsql 8.2.4, getting worse performance then 7.4.x
  • From: Gregory Stark
• Re: dbt2 NOTPM numbers
  • From: Heikki Linnakangas
• Re: Thousands of tables versus on table?
  • From: Scott Marlowe
• Re: Thousands of tables versus on table?
  • From: Gregory Stark
• Re: Thousands of tables versus on table?
  • From: PFC
• Re: Thousands of tables versus on table?
  • From: Thomas Andrews
• Re: Thousands of tables versus on table?
  • From: Y Sidhu
• Re: upgraded to pgsql 8.2.4, getting worse performance then 7.4.x
  • From: Douglas J Hunley
• Re: Thousands of tables versus on table?
  • From: Thomas Andrews
• Re: Thousands of tables versus on table?
  • From: Gregory Stark
• Re: Thousands of tables versus on table?
  • From: Thomas Andrews
• Re: dbt2 NOTPM numbers
  • From: Markus Schiltknecht
• Re: Thousands of tables versus on table?
  • From: Thomas Andrews
• Re: Thousands of tables versus on table?
  • From: Mark Lewis
• Re: upgraded to pgsql 8.2.4, getting worse performance then 7.4.x
  • From: Alvaro Herrera
• Thousands of tables versus on table?
  • From: Thomas Andrews
• Re: upgraded to pgsql 8.2.4, getting worse performance then 7.4.x
  • From: Douglas J Hunley
• Re: dbt2 NOTPM numbers
  • From: PFC
• Re: dbt2 NOTPM numbers
  • From: Markus Schiltknecht
• Re: dbt2 NOTPM numbers
  • From: Heikki Linnakangas
• dbt2 NOTPM numbers
  • From: Markus Schiltknecht
• Re: upgraded to pgsql 8.2.4, getting worse performance then 7.4.x
  • From: Reid Thompson
• Re: upgraded to pgsql 8.2.4, getting worse performance then 7.4.x
  • From: Luke Lonergan
• Re: upgraded to pgsql 8.2.4, getting worse performance then 7.4.x
  • From: Heikki Linnakangas
• Re: upgraded to pgsql 8.2.4, getting worse performance then 7.4.x
  • From: Douglas J Hunley
• Re: upgraded to pgsql 8.2.4, getting worse performance then 7.4.x
  • From: Tom Lane
• Re: upgraded to pgsql 8.2.4, getting worse performance then 7.4.x
  • From: Greg Smith
• Re: upgraded to pgsql 8.2.4, getting worse performance then 7.4.x
  • From: Luke Lonergan
• Re: upgraded to pgsql 8.2.4, getting worse performance then 7.4.x
  • From: Douglas J Hunley
• Re: upgraded to pgsql 8.2.4, getting worse performance then 7.4.x
  • From: Douglas J Hunley
• Re: Append table
  • From: Hanu Kurubar
• Re: Postgres Benchmark Results
  • From: Josh Berkus
• Re: Append table
  • From: Gregory Stark
• Re: Append table
  • From: Arjen van der Meijden
• Re: Append table
  • From: Hanu Kurubar
• Re: upgraded to pgsql 8.2.4, getting worse performance then 7.4.x
  • From: Kenneth Marshall
• Re: upgraded to pgsql 8.2.4, getting worse performance then 7.4.x
  • From: Stefan Kaltenbrunner
• Re: upgraded to pgsql 8.2.4, getting worse performance then 7.4.x
  • From: Tom Lane
• Re: upgraded to pgsql 8.2.4, getting worse performance then 7.4.x
  • From: Michael Fuhr
• Re: upgraded to pgsql 8.2.4, getting worse performance then 7.4.x
  • From: Rafael Martinez
• upgraded to pgsql 8.2.4, getting worse performance then 7.4.x
  • From: Douglas J Hunley
• Re: Autodetect of software RAID1+0 fails
  • From: Luke Lonergan
• Re: Autodetect of software RAID1+0 fails
  • From: mark
• Re: Autodetect of software RAID1+0 fails
  • From: Steinar H. Gunderson
• Re: Autodetect of software RAID1+0 fails
  • From: Luke Lonergan
• PostgreSQL not fully utilizing system resources?
  • From: Gregory Stewart
• Re: Autodetect of software RAID1+0 fails
  • From: Dimitri
• Autodetect of software RAID1+0 fails
  • From: Craig James
• Re: Seq Scan
  • From: Michael Glaesemann
• Re: Seq Scan
  • From: Dan Harris
• Seq Scan
  • From: Tyler Durden
• [no subject]
  • From: Unknown
• Re: Performance Woes
  • From: Jeff Davis
• Re: Performance Woes
  • From: Joshua D. Drake
• Re: Performance Woes
  • From: Ralph Mason
• Re: Performance Woes
  • From: Joshua D. Drake
• Re: Performance Woes
  • From: CAJ CAJ
• Performance Woes
  • From: Ralph Mason
• Vacuum Times - Verbose and maintenance_work_mem
  • From: Y Sidhu
• Re: Cannot make GIN intarray index be used by the planner
  • From: Tom Lane
• Re: Cannot make GIN intarray index be used by the planner
  • From: Valentine Gogichashvili
• Re: ZFS and Postgresql - WASRe: Best OS for Postgres 8.2
  • From: david
• Re: ZFS and Postgresql - WASRe: Best OS for Postgres 8.2
  • From: Jignesh Shah
• Re: Nested loops overpriced
  • From: Tom Lane
• Re: How to Find Cause of Long Vacuum Times - NOOB Question
  • From: Jim Nasby
• Re: Best OS for Postgres 8.2
  • From: Jim Nasby
• Re: ZFS and Postgresql - WASRe: Best OS for Postgres 8.2
  • From: Alvaro Herrera
• ZFS and Postgresql - WASRe: Best OS for Postgres 8.2
  • From: Jignesh Shah
• Re: Nested loops overpriced
  • From: Peter Eisentraut
• Re: Apparently useless bitmap scans
  • From: Tom Lane
• Re: Apparently useless bitmap scans
  • From: Peter Eisentraut
• Re: Nested loops overpriced
  • From: Daniel Cristian Cruz
• Re: Apparently useless bitmap scans
  • From: Tom Lane
• Re: Nested loops overpriced
  • From: Gregory Stark
• Re: Poor performance with queries using clause: sth IN (...)
  • From: Gregory Stark
• Re: Apparently useless bitmap scans
  • From: Alvaro Herrera
• Re: Throttling PostgreSQL's CPU usage
  • From: Carlos Moreno
• Re: Nested loops overpriced
  • From: Tom Lane
• Re: Cannot make GIN intarray index be used by the planner
  • From: Oleg Bartunov
• Re: Throttling PostgreSQL's CPU usage
  • From: Daniel Griscom
• Re: Nested loops overpriced
  • From: Daniel Cristian Cruz
• Re: Cannot make GIN intarray index be used by the planner
  • From: Valentine Gogichashvili
• Re: Cannot make GIN intarray index be used by the planner
  • From: Oleg Bartunov
• Poor performance with queries using clause: sth IN (...)
  • From: Andrzej Zawadzki
• Cannot make GIN intarray index be used by the planner
  • From: Valentine Gogichashvili
• Apparently useless bitmap scans
  • From: Peter Eisentraut
• Re: Nested loops overpriced
  • From: Peter Eisentraut
• Re: FW:
  • From: Gregory Stark
• Re: What's The Difference Between VACUUM and VACUUM ANALYZE?
  • From: Gregory Stark
• Re: Best OS for Postgres 8.2
  • From: david
• Re: Best OS for Postgres 8.2
  • From: Steinar H. Gunderson
• Re: estimating the need for VACUUM FULL and REINDEX
  • From: Guillaume Cottenceau
• Re: Best OS for Postgres 8.2
  • From: david
• Re: Throttling PostgreSQL's CPU usage
  • From: Magnus Hagander
• Re:
  • From: Robert Treat
• Re:
  • From: Greg Smith
• Re: Throttling PostgreSQL's CPU usage
  • From: Luke Lonergan
• Re: Best OS for Postgres 8.2
  • From: Greg Smith
• Re: Best OS for Postgres 8.2
  • From: Greg Smith
• Re: FW:
  • From: david
• FW:
  • From: Orhan Aglagul
• FW:
  • From: Orhan Aglagul
• FW:
  • From: Orhan Aglagul
• Re:
  • From: Orhan Aglagul
• Re:
  • From: Scott Marlowe
• Re:
  • From: Scott Marlowe
• Re:
  • From: Carlos Moreno
• Re:
  • From: Joshua D. Drake
• Re:
  • From: Dan Harris
• [no subject]
  • From: Orhan Aglagul
• Re: Throttling PostgreSQL's CPU usage
  • From: david
• Re: Throttling PostgreSQL's CPU usage
  • From: david
• Re: Throttling PostgreSQL's CPU usage
  • From: Carlos Moreno
• Re: Throttling PostgreSQL's CPU usage
  • From: Steinar H. Gunderson
• Re: Throttling PostgreSQL's CPU usage
  • From: Daniel Griscom
• Re: Throttling PostgreSQL's CPU usage
  • From: Carlos Moreno
• Re: Throttling PostgreSQL's CPU usage
  • From: Steinar H. Gunderson
• Re: Throttling PostgreSQL's CPU usage
  • From: Joshua D. Drake
• Re: Throttling PostgreSQL's CPU usage
  • From: Carlos Moreno
• Re: What's The Difference Between VACUUM and VACUUM ANALYZE?
  • From: Alvaro Herrera
• Re: What's The Difference Between VACUUM and VACUUM ANALYZE?
  • From: Steinar H. Gunderson
• Re: What's The Difference Between VACUUM and VACUUM ANALYZE?
  • From: Alvaro Herrera
• Re: What's The Difference Between VACUUM and VACUUM ANALYZE?
  • From: david
• What's The Difference Between VACUUM and VACUUM ANALYZE?
  • From: Y Sidhu
• Re: Throttling PostgreSQL's CPU usage
  • From: Mark Lewis
• Re: Throttling PostgreSQL's CPU usage
  • From: david
• Re: Throttling PostgreSQL's CPU usage
  • From: Bill Moran
• Re: Throttling PostgreSQL's CPU usage
  • From: Steinar H. Gunderson
• Re: Best OS for Postgres 8.2
  • From: Charles Sprickman
• Throttling PostgreSQL's CPU usage
  • From: Daniel Griscom
• Re: DISTINCT Question
  • From: Scott Marlowe
• Re: DISTINCT Question
  • From: Joshua D. Drake
• Re: DISTINCT Question
  • From: Steinar H. Gunderson
• DISTINCT Question
  • From: Y Sidhu
• Re: Query performance problems with partitioned tables
  • From: Scott Marlowe
• Re: Query performance problems with partitioned tables
  • From: Fei Liu
• Re: truncate a table instead of vaccum full when count(*) is 0
  • From: Pomarede Nicolas
• Re: Best OS for Postgres 8.2
  • From: 李彦 Ian Li
• Re: specific query (not all) on Pg8 MUCH slower than Pg7
  • From: Tom Lane
• Re: Best OS for Postgres 8.2
  • From: Ron
• Re: Nested loops overpriced
  • From: Tom Lane
• Re: specific query (not all) on Pg8 MUCH slower than Pg7
  • From: Alvaro Herrera
• Re: specific query (not all) on Pg8 MUCH slower than Pg7
  • From: Susan Russo
• Nested loops overpriced
  • From: Peter Eisentraut
• Re: specific query (not all) on Pg8 MUCH slower than Pg7
  • From: Tom Lane
• Re: specific query (not all) on Pg8 MUCH slower than Pg7
  • From: Bill Moran
• Re: specific query (not all) on Pg8 MUCH slower than Pg7
  • From: Alexander Staubo
• Re: specific query (not all) on Pg8 MUCH slower than Pg7
  • From: Richard Broersma Jr
• Re: specific query (not all) on Pg8 MUCH slower than Pg7
  • From: Steinar H. Gunderson
• Re: [PERFORM] specific query (not all) on Pg8 MUCH slower than Pg7
  • From: Steinar H. Gunderson
• Re: specific query (not all) on Pg8 MUCH slower than Pg7
  • From: Tom Lane
• specific query (not all) on Pg8 MUCH slower than Pg7
  • From: Susan Russo
• Re: estimating the need for VACUUM FULL and REINDEX
  • From: Bill Moran
• Re: estimating the need for VACUUM FULL and REINDEX
  • From: Heikki Linnakangas
• Re: [OT] Best OS for Postgres 8.2
  • From: Adam Tauno Williams
• estimating the need for VACUUM FULL and REINDEX
  • From: Guillaume Cottenceau
• Re: Best OS for Postgres 8.2
  • From: Luke Lonergan
• Re: truncate a table instead of vaccum full when count(*) is 0
  • From: Heikki Linnakangas
• Re: truncate a table instead of vaccum full when count(*) is 0
  • From: Guillaume Cottenceau
• Re: [OT] Best OS for Postgres 8.2
  • From: "C. Bergström"
• Re: truncate a table instead of vaccum full when count(*) is 0
  • From: Heikki Linnakangas
• Re: truncate a table instead of vaccum full when count(*) is 0
  • From: Pomarede Nicolas
• Re: truncate a table instead of vaccum full when count(*) is 0
  • From: Gregory Stark
• Re: Best OS for Postgres 8.2
  • From: Trygve Laugstøl
• Re: truncate a table instead of vaccum full when count(*) is 0
  • From: Heikki Linnakangas
• Re: Best OS for Postgres 8.2
  • From: david
• Re: truncate a table instead of vaccum full when count(*) is 0
  • From: ismo . tuononen
• Re: truncate a table instead of vaccum full when count(*) is 0
  • From: Pomarede Nicolas
• Re: truncate a table instead of vaccum full when count(*) is 0
  • From: Gregory Stark
• Re: Best OS for Postgres 8.2
  • From: david
• Re: truncate a table instead of vaccum full when count(*) is 0
  • From: Pomarede Nicolas
• Re: truncate a table instead of vaccum full when count(*) is 0
  • From: Pomarede Nicolas
• Re: truncate a table instead of vaccum full when count(*) is 0
  • From: Heikki Linnakangas
• Re: truncate a table instead of vaccum full when count(*) is 0
  • From: Guillaume Cottenceau
• Re: Best OS for Postgres 8.2
  • From: Steinar H. Gunderson
• Re: Best OS for Postgres 8.2
  • From: Alexander Staubo
• truncate a table instead of vaccum full when count(*) is 0
  • From: Pomarede Nicolas
• Re: Best OS for Postgres 8.2
  • From: Steinar H. Gunderson
• Re: Best OS for Postgres 8.2
  • From: Trygve Laugstøl
• Re: Best OS for Postgres 8.2
  • From: david
• Re: Best OS for Postgres 8.2
  • From: Claus Guttesen
• Re: Best OS for Postgres 8.2
  • From: Heikki Linnakangas
• Re: Best OS for Postgres 8.2
  • From: Claus Guttesen
• Re: Best OS for Postgres 8.2
  • From: david
• Re: Best OS for Postgres 8.2
  • From: 李彦 Ian Li
• Re: Best OS for Postgres 8.2
  • From: Tom Lane
• Re: How to Find Cause of Long Vacuum Times - NOOB Question
  • From: Yudhvir Singh Sidhu
• Re: Best OS for Postgres 8.2
  • From: Greg Smith
• Re: Best OS for Postgres 8.2
  • From: Ron
• Re: Best OS for Postgres 8.2
  • From: Chris
• Re: Best OS for Postgres 8.2
  • From: david
• Re: Best OS for Postgres 8.2
  • From: Chris
• Re: Best OS for Postgres 8.2
  • From: Steve Atkins
• Re: Best OS for Postgres 8.2
  • From: Joshua D. Drake
• Re: Best OS for Postgres 8.2
  • From: Bill Moran
• Re: Best OS for Postgres 8.2
  • From: Joshua D. Drake
• Best OS for Postgres 8.2
  • From: David Levy
• Re: How to Find Cause of Long Vacuum Times - NOOB Question
  • From: Jim Nasby
• Re: Merging large volumes of data
  • From: Tom Lane
• Re: Merging large volumes of data
  • From: Gregory Stark
• Re: Merging large volumes of data
  • From: Andreas Kostyrka
• Merging large volumes of data
  • From: Ambrus Wagner (IJ/ETH)
• Re: Index not being used in sorting of simple table
  • From: Tom Lane
• Re: Index not being used in sorting of simple table
  • From: Robins
• Re: How to Find Cause of Long Vacuum Times - NOOB Question
  • From: Yudhvir Singh Sidhu
• Re: How to Find Cause of Long Vacuum Times - NOOB Question
  • From: Steinar H. Gunderson
• Re: How to Find Cause of Long Vacuum Times - NOOB Question
  • From: Heikki Linnakangas
• Re: Feature Request --- was: PostgreSQL Performance Tuning
  • From: Andreas Kostyrka
• Re: Feature Request --- was: PostgreSQL Performance Tuning
  • From: Jim Nasby
• Re: How to Find Cause of Long Vacuum Times - NOOB Question
  • From: Yudhvir Singh Sidhu
• Re: How to Find Cause of Long Vacuum Times - NOOB Question
  • From: Steinar H. Gunderson
• How to Find Cause of Long Vacuum Times - NOOB Question
  • From: Yudhvir Singh Sidhu
• Re: Feature Request --- was: PostgreSQL Performance Tuning
  • From: Sebastian Hennebrueder
• Re: Feature Request --- was: PostgreSQL Performance Tuning
  • From: Steinar H. Gunderson
• Re: Feature Request --- was: PostgreSQL Performance Tuning
  • From: Mark Kirkwood
• Re: Feature Request --- was: PostgreSQL Performance Tuning
  • From: Greg Smith
• Re: Feature Request --- was: PostgreSQL Performance Tuning
  • From: Sebastian Hennebrueder
• Re: Feature Request --- was: PostgreSQL Performance Tuning
  • From: Josh Berkus
• Re: Query performance problems with partitioned tables
  • From: Merlin Moncure
• Re: Feature Request --- was: PostgreSQL Performance Tuning
  • From: Sebastian Hennebrueder
• Re: Index not being used in sorting of simple table
  • From: Paul Smith
• Re: Index not being used in sorting of simple table
  • From: Tom Lane
• Re: Index not being used in sorting of simple table
  • From: Heikki Linnakangas
• Re: Query performance problems with partitioned tables
  • From: Scott Marlowe
• Index not being used in sorting of simple table
  • From: Paul Smith
• Re: pg_stat_* collection
  • From: Michael Stone
• Re: Feature Request --- was: PostgreSQL Performance Tuning
  • From: Michael Stone
• Re: pg_stat_* collection
  • From: Tobias Brox
• Re: pg_stat_* collection
  • From: Greg Smith
• Re: Feature Request --- was: PostgreSQL Performance Tuning
  • From: Greg Smith
• Re: Query performance problems with partitioned tables
  • From: Merlin Moncure
• Re: Feature Request --- was: PostgreSQL Performance Tuning
  • From: david
• Re: Feature Request --- was: PostgreSQL Performance Tuning
  • From: Carlos Moreno
• Re: Feature Request --- was: PostgreSQL Performance Tuning
  • From: david
• Re: Feature Request --- was: PostgreSQL Performance Tuning
  • From: Carlos Moreno
• Re: Feature Request --- was: PostgreSQL Performance Tuning
  • From: david
• Re: Feature Request --- was: PostgreSQL Performance Tuning
  • From: Carlos Moreno
• Re: Feature Request --- was: PostgreSQL Performance Tuning
  • From: david
• Re: Feature Request --- was: PostgreSQL Performance Tuning
  • From: Carlos Moreno
• Re: Feature Request --- was: PostgreSQL Performance Tuning
  • From: david
• Re: Feature Request --- was: PostgreSQL Performance Tunin g
  • From: Dave Page
• Re: Feature Request --- was: PostgreSQL Performance Tuning
  • From: Josh Berkus
• Re: Feature Request --- was: PostgreSQL Performance Tuning
  • From: Ron
• Re: pg_stat_* collection
  • From: Jeff Davis
• Re: pg_stat_* collection
  • From: Tobias Brox
• Re: pg_stat_* collection
  • From: Magnus Hagander
• Re: Query performance problems with partitioned tables
  • From: Fei Liu
• Re: pg_stat_* collection
  • From: Alexander Staubo
• pg_stat_* collection
  • From: Greg Smith
• Re: Join vs Subquery
  • From: Tom Lane
• Re: Join vs Subquery
  • From: Gregory Stark
• Re: Intermitent slow queries
  • From: Ron
• Join vs Subquery
  • From: Brian Herlihy
• Re: Intermitent slow queries
  • From: Parks, Aaron B.
• Re: Intermitent slow queries
  • From: Parks, Aaron B.
• Re: Intermitent slow queries
  • From: Steinar H. Gunderson
• Re: Intermitent slow queries
  • From: Ron
• Re: Intermitent slow queries
  • From: Dave Cramer
• Intermitent slow queries
  • From: Parks, Aaron B.
• Re: Feature Request --- was: PostgreSQL Performance Tuning
  • From: david
• Re: Feature Request --- was: PostgreSQL Performance Tuning
  • From: Greg Smith
• Re: Feature Request --- was: PostgreSQL Performance Tuning
  • From: Greg Smith
• Re: Feature Request --- was: PostgreSQL Performance Tuning
  • From: david
• Re: Feature Request --- was: PostgreSQL Performance Tuning
  • From: Carlos Moreno
• Re: index structure for 114-dimension vector
  • From: Alexander Staubo
• Re: index structure for 114-dimension vector
  • From: Andrew Lazarus
• Re: sytem log audit/reporting and psql
  • From: Andreas Haumer
• Re: Feature Request --- was: PostgreSQL Performance Tuning
  • From: Josh Berkus
• Re: Query performance problems with partitioned tables
  • From: Gregory Stark
• Re: Feature Request --- was: PostgreSQL Performance Tuning
  • From: Kevin Hunter
• Re: Query performance problems with partitioned tables
  • From: Steinar H. Gunderson
• Re: Query performance problems with partitioned tables
  • From: Andreas Haumer
• Re: Query performance problems with partitioned tables
  • From: Andreas Haumer
• Re: Feature Request --- was: PostgreSQL Performance Tuning
  • From: Craig A. James
• Re: Query performance problems with partitioned tables
  • From: Gregory Stark
• Re: Query performance problems with partitioned tables
  • From: Tom Lane
• sytem log audit/reporting and psql
  • From: Fei Liu
• Re: Query performance problems with partitioned tables
  • From: Neil Peter Braggio
• Re: Query performance problems with partitioned tables
  • From: Guillaume Cottenceau
• Re: Query performance problems with partitioned tables
  • From: Richard Huxton
• Re: Query performance problems with partitioned tables
  • From: Andreas Haumer
• Re: Query performance problems with partitioned tables
  • From: Guillaume Cottenceau
• Query performance problems with partitioned tables
  • From: Andreas Haumer
• Re: Feature Request --- was: PostgreSQL Performance Tuning
  • From: Greg Smith
• Re: Redundant sub query triggers slow nested loop left join
  • From: henk de wit
• Re: Very specific server situation
  • From: Mauro N. Infantino
• Re: Feature Request --- was: PostgreSQL Performance Tuning
  • From: Carlos Moreno
• Re: Usage up to 50% CPU
  • From: Andres Retzlaff
• Re: Feature Request --- was: PostgreSQL Performance Tuning
  • From: Harald Armin Massa
• Re: Feature Request --- was: PostgreSQL Performance Tuning
  • From: Jonah H. Harris
• Re: Redundant sub query triggers slow nested loop left join
  • From: henk de wit
• Re: Feature Request --- was: PostgreSQL Performance Tuning
  • From: Harald Armin Massa
• Re: Feature Request --- was: PostgreSQL Performance Tuning
  • From: david
• Re: Feature Request --- was: PostgreSQL Performance Tuning
  • From: Josh Berkus
• Re: Very specific server situation
  • From: Tom Lane
• Re: Feature Request --- was: PostgreSQL Performance Tuning
  • From: Dan Harris
• Re: Feature Request --- was: PostgreSQL Performance Tuning
  • From: Josh Berkus
• Re: Feature Request --- was: PostgreSQL Performance Tuning
  • From: Ray Stell
• Re: Feature Request --- was: PostgreSQL Performance Tuning
  • From: Kevin Hunter
• Re: Feature Request --- was: PostgreSQL Performance Tuning
  • From: Bill Moran
• Re: Feature Request --- was: PostgreSQL Performance Tuning
  • From: Josh Berkus
• Re: Feature Request --- was: PostgreSQL Performance Tuning
  • From: Dan Harris
• Very specific server situation
  • From: Mauro N. Infantino
• Re: How can fixed and variable width columns perform similarly?
  • From: Tom Lane
• Re: How can fixed and variable width columns perform similarly?
  • From: Siddharth Anand
• Re: How can fixed and variable width columns perform similarly?
  • From: Dave Dutcher
• Re: [Fwd: ] How
  • From: Richard Huxton
• Re: How can fixed and variable width columns perform similarly?
  • From: Tom Lane
• Re: Feature Request --- was: PostgreSQL Performance Tuning
  • From: Jim Nasby
• How can fixed and variable width columns perform similarly?
  • From: Siddharth Anand
• [Fwd: ] How
  • From: Siddharth Anand
• Re: Feature Request --- was: PostgreSQL Performance Tuning
  • From: Michael Stone
• Re: Feature Request --- was: PostgreSQL Performance Tuning
  • From: H.J. Sanders
• Re: Feature Request --- was: PostgreSQL Performance Tuning
  • From: Mark Lewis
• Re: Feature Request --- was: PostgreSQL Performance Tuning
  • From: Tom Lane
• Re: Feature Request --- was: PostgreSQL Performance Tuning
  • From: Michael Stone
• Re: What`s wrong with JFS configuration?
  • From: Jim Nasby
• Re: Feature Request --- was: PostgreSQL Performance Tuning
  • From: Carlos Moreno
• Re: Usage up to 50% CPU
  • From: Michael Stone
• Re: Usage up to 50% CPU
  • From: Shane Ambler
• Re: Usage up to 50% CPU
  • From: Magnus Hagander
• Re: Usage up to 50% CPU
  • From: Andres Retzlaff
• Re: Usage up to 50% CPU
  • From: Magnus Hagander
• Re: Filesystem fragmentation (Re: Fragmentation of WAL files)
  • From: Florian Weimer
• Re: index structure for 114-dimension vector
  • From: Arjen van der Meijden
• Re: Fragmentation of WAL files
  • From: Greg Smith
• Re: Simple query, 10 million records...MySQL ten times faster
  • From: Oleg Bartunov
• Re: index structure for 114-dimension vector
  • From: Oleg Bartunov
• Usage up to 50% CPU
  • From: Andres Retzlaff
• Re: Feature Request --- was: PostgreSQL Performance Tuning
  • From: Tom Lane
• Feature Request --- was: PostgreSQL Performance Tuning
  • From: Carlos Moreno
• Re: Simple query, 10 million records...MySQL ten times faster
  • From: joe
• Re: postgres: 100% CPU utilization
  • From: Mark Kirkwood
• Re: Simple query, 10 million records...MySQL ten times faster
  • From: Alexander Staubo
• Re: Simple query, 10 million records...MySQL ten times faster
  • From: Alexander Staubo
• Re: postgres: 100% CPU utilization
  • From: Scott Marlowe
• Re: Simple query, 10 million records...MySQL ten times faster
  • From: Jeff Hoffmann
• Re: Simple query, 10 million records...MySQL ten times faster
  • From: Scott Marlowe
• Re: index structure for 114-dimension vector
  • From: Alexander Staubo
• Re: Simple query, 10 million records...MySQL ten times faster
  • From: Luke Lonergan
• Re: Simple query, 10 million records...MySQL ten times faster
  • From: Benjamin Minshall
• Re: Simple query, 10 million records...MySQL ten times faster
  • From: Bill Moran
• Re: Simple query, 10 million records...MySQL ten times faster
  • From: Merlin Moncure
• Re: [GENERAL] PostgreSQL Performance Tuning
  • From: Steve Crawford
• Re: not using indexes on large table
  • From: Scott Marlowe
• Re: Filesystem fragmentation (Re: Fragmentation of WAL files)
  • From: Tom Lane
• Re: [GENERAL] Fw: PostgreSQL Performance Tuning
  • From: Gerhard Wiesinger
• Re: Filesystem fragmentation (Re: Fragmentation of WAL files)
  • From: Gregory Stark
• Re: Filesystem fragmentation (Re: Fragmentation of WAL files)
  • From: Craig A. James
• Re: Fragmentation of WAL files
  • From: Tom Lane
• Filesystem fragmentation (Re: Fragmentation of WAL files)
  • From: Bill Moran
• Re: Fragmentation of WAL files
  • From: Heikki Linnakangas
• Re: Fragmentation of WAL files
  • From: Bill Moran
• Re: [GENERAL] Fw: PostgreSQL Performance Tuning
  • From: Richard Huxton
• Re: Fw: PostgreSQL Performance Tuning
  • From: Richard Huxton
• Fw: PostgreSQL Performance Tuning
  • From: Shohab Abdullah
• Re: What`s wrong with JFS configuration?
  • From: Cosimo Streppone
• Re: seeking advise on char vs text or varchar in search table
  • From: Gregory Stark
• Re: What`s wrong with JFS configuration?
  • From: Luke Lonergan
• Re: What`s wrong with JFS configuration?
  • From: Jim Nasby
• Re: seeking advise on char vs text or varchar in search table
  • From: Jim Nasby
• Fragmentation of WAL files
  • From: Jim Nasby
• Re: What`s wrong with JFS configuration?
  • From: Greg Smith
• Re: What`s wrong with JFS configuration?
  • From: Chris Browne
• Re: What`s wrong with JFS configuration?
  • From: Paweł Gruszczyński
• Re: What`s wrong with JFS configuration?
  • From: Dave Cramer
• Re: What`s wrong with JFS configuration?
  • From: Heikki Linnakangas
• What`s wrong with JFS configuration?
  • From: Paweł Gruszczyński
• Simple query, 10 million records...MySQL ten times faster
  • From: zardozrocks
• Re: View is not using a table index
  • From: Carlos Moreno
• Re: View is not using a table index
  • From: Tom Lane
• Re: View is not using a table index
  • From: Andreas Kostyrka
• Re: View is not using a table index
  • From: Dan Shea
• Re: View is not using a table index
  • From: Richard Huxton
• Re: postgres: 100% CPU utilization
  • From: Sergey Tsukinovsky
• View is not using a table index
  • From: Dan Shea
• Re: Warm - standby system.
  • From: Alexander Staubo
• Re: TPC-H Scaling Factors X PostgreSQL Cluster Command
  • From: Heikki Linnakangas
• Warm - standby system.
  • From: Nimesh Satam
• Re: postgres: 100% CPU utilization
  • From: Greg Smith
• Re: TPC-H Scaling Factors X PostgreSQL Cluster Command
  • From: Greg Smith
• Re: postgres: 100% CPU utilization
  • From: Mark Kirkwood
• Re: postgres: 100% CPU utilization
  • From: Scott Marlowe
• Re: postgres: 100% CPU utilization
  • From: Vivek Khera
• Re: TPC-H Scaling Factors X PostgreSQL Cluster Command
  • From: Kevin Grittner
• Re: index usage
  • From: Steinar H. Gunderson
• Re: index structure for 114-dimension vector
  • From: C Storm
• index usage
  • From: Arkadiusz Raj
• Re: postgres: 100% CPU utilization
  • From: Scott Marlowe
• Re: TPC-H Scaling Factors X PostgreSQL Cluster Command
  • From: Nelson Kotowski
• Re: postgres: 100% CPU utilization
  • From: Ron
• Re: not using indexes on large table
  • From: Dave Dutcher
• Re: Redundant sub query triggers slow nested loop left join
  • From: henk de wit
• Re: TPC-H Scaling Factors X PostgreSQL Cluster Command
  • From: Heikki Linnakangas
• Re: postgres: 100% CPU utilization
  • From: Mario Weilguni
• Re: Help with TOAST Compression
  • From: Michael Fuhr
• Re: postgres: 100% CPU utilization
  • From: Andreas Tille
• Re: seeking advise on char vs text or varchar in search table
  • From: Merlin Moncure
• Re: postgres: 100% CPU utilization
  • From: Tom Lane
• Re: Redundant sub query triggers slow nested loop left join
  • From: Tom Lane
• Re: Redundant sub query triggers slow nested loop left join
  • From: henk de wit
• Re: Redundant sub query triggers slow nested loop left join
  • From: henk de wit
• Re: Redundant sub query triggers slow nested loop left join
  • From: Tom Lane
• Re: Redundant sub query triggers slow nested loop left join
  • From: henk de wit
• Re: Redundant sub query triggers slow nested loop left join
  • From: Tom Lane
• Re: Redundant sub query triggers slow nested loop left join
  • From: henk de wit
• Re: Large objetcs performance
  • From: Ulrich Cech
• Re: Odd problem with planner choosing seq scan
  • From: Tom Lane
• Re: Odd problem with planner choosing seq scan
  • From: Colin McGuigan
• Re: Redundant sub query triggers slow nested loop left join
  • From: Tom Lane
• Redundant sub query triggers slow nested loop left join
  • From: henk de wit
• Re: not using indexes on large table
  • From: Andreas Kostyrka
• Re: not using indexes on large table
  • From: Vincenzo Romano
• not using indexes on large table
  • From: Jeroen Kleijer
• Re: Odd problem with planner choosing seq scan
  • From: Tom Lane
• Re: FK triggers misused?
  • From: Stephan Szabo
• Odd problem with planner choosing seq scan
  • From: Colin McGuigan
• TPC-H Scaling Factors X PostgreSQL Cluster Command
  • From: Nelson Kotowski
• Re: FK triggers misused?
  • From: cluster
• Re: Large objetcs performance
  • From: Ulrich Cech
• Odd problem with planner choosing seq scan
  • From: Colin McGuigan
• Re: index structure for 114-dimension vector
  • From: Tom Lane
• Re: index structure for 114-dimension vector
  • From: Mark Kirkwood
• Re: index structure for 114-dimension vector
  • From: Andrew Lazarus
• Re: index structure for 114-dimension vector
  • From: Mark Kirkwood
• Re: index structure for 114-dimension vector
  • From: Jeff Davis
• index structure for 114-dimension vector
  • From: Andrew Lazarus
• seeking advise on char vs text or varchar in search table
  • From: chrisj
• postgres: 100% CPU utilization
  • From: Sergey Tsukinovsky
• Re: how to output column names
  • From: Michael Dengler
• Re: how to output column names
  • From: Jon Sime
• how to output column names
  • From: Michael Dengler
• Re: Foreign Key Deadlocking
  • From: Csaba Nagy
• Re: Foreign Key Deadlocking
  • From: Alvaro Herrera
• Re: Foreign Key Deadlocking
  • From: Erik Jones
• Re: Foreign Key Deadlocking
  • From: Dave Cramer
• Re: Basic Q on superfluous primary keys
  • From: Merlin Moncure
• Re: Foreign Key Deadlocking
  • From: Steven Flatt
• Re: Equivalents in PostgreSQL of MySQL's "ENGINE=MEMORY" "MAX_ROWS=1000"
  • From: Hannes Dorbath
• Re: Basic Q on superfluous primary keys
  • From: Jeff Davis
• Re: Long running transactions again ...
  • From: Jim C. Nasby
• Re: Basic Q on superfluous primary keys
  • From: Dave Dutcher
• Re: a question about Direct I/O and double buffering
  • From: Jim C. Nasby
• Re: Foreign Key Deadlocking
  • From: Tom Lane
• Re: Shared buffers, db transactions commited, and write IO on Solaris
  • From: Jim C. Nasby
• Re: Basic Q on superfluous primary keys
  • From: Craig A. James
• Re: Foreign Key Deadlocking
  • From: Csaba Nagy
• Foreign Key Deadlocking
  • From: Steven Flatt
• Re: Basic Q on superfluous primary keys
  • From: Merlin Moncure
• Re: Basic Q on superfluous primary keys
  • From: Greg Smith
• Re: Basic Q on superfluous primary keys
  • From: Richard Huxton
• Re: Basic Q on superfluous primary keys
  • From: Craig A. James
• Re: Basic Q on superfluous primary keys
  • From: Craig A. James
• Help with TOAST Compression
  • From: David Hinkle
• Re: FK triggers misused?
  • From: cluster
• Re: Basic Q on superfluous primary keys
  • From: Merlin Moncure
• Re: Fwd: Strangely Variable Query Performance
  • From: Tom Lane
• Fwd: Strangely Variable Query Performance
  • From: Robins
• Fwd: Strangely Variable Query Performance
  • From: Robins Tharakan
• Re: Basic Q on superfluous primary keys
  • From: Greg Smith
• Re: FK triggers misused?
  • From: Tom Lane
• Re: FK triggers misused?
  • From: Tom Lane
• Re: FK triggers misused?
  • From: cluster
• Re: Basic Q on superfluous primary keys
  • From: Ron Mayer
• Re: Basic Q on superfluous primary keys
  • From: Merlin Moncure
• Re: Basic Q on superfluous primary keys
  • From: Craig A. James
• Re: Basic Q on superfluous primary keys
  • From: Merlin Moncure
• Re: FK triggers misused?
  • From: Andrew - Supernews
• Re: FK triggers misused?
  • From: Tom Lane
• Re: FK triggers misused?
  • From: Andrew - Supernews
• Re: FK triggers misused?
  • From: Tom Lane
• Re: [HACKERS] choose_bitmap_and again (was Re: Strangely Variable Query Performance)
  • From: Tom Lane
• Re: [HACKERS] choose_bitmap_and again (was Re: Strangely Variable Query Performance)
  • From: Tom Lane
• Re: Question about memory allocations
  • From: Tom Lane
• Re: [HACKERS] choose_bitmap_and again (was Re: Strangely Variable Query Performance)
  • From: Tom Lane
• FK triggers misused?
  • From: cluster
• Re: Basic Q on superfluous primary keys
  • From: Bill Moran
• Basic Q on superfluous primary keys
  • From: Kynn Jones
• Re: Finding bloated indexes?
  • From: Simon Riggs
• Re: [HACKERS] choose_bitmap_and again (was Re: Strangely Variable Query Performance)
  • From: Alvaro Herrera
• choose_bitmap_and again (was Re: Strangely Variable Query Performance)
  • From: Tom Lane
• Re: Finding bloated indexes?
  • From: Vivek Khera
• Re: Please humor me ...
  • From: Simon Riggs
• Re: Question about memory allocations
  • From: Jan de Visser
• Finding bloated indexes?
  • From: Dan Harris
• Re: Question about memory allocations
  • From: Carlos Moreno
• Re: Question about memory allocations
  • From: Ron
• Re: Question about memory allocations
  • From: Steve
• Re: local selectivity estimation - computing frequency of predicates
  • From: Tom Lane
• local selectivity estimation - computing frequency of predicates
  • From: Avdhoot Kishore Saple
• Re: Question about memory allocations
  • From: Andrew McMillan
• Re: Strangely Variable Query Performance
  • From: Tom Lane
• Re: Question about memory allocations
  • From: Steve
• Re: Strangely Variable Query Performance
  • From: Steve
• Re: Strangely Variable Query Performance
  • From: Tom Lane
• Re: Question about memory allocations
  • From: Greg Smith
• Re: Strangely Variable Query Performance
  • From: Tom Lane
• Re: Strangely Variable Query Performance
  • From: Steve
• Re: Strangely Variable Query Performance
  • From: Tom Lane
• Re: Strangely Variable Query Performance
  • From: Steve
• Re: Strangely Variable Query Performance
  • From: Tom Lane
• Re: Strangely Variable Query Performance
  • From: Steve
• Re: Strangely Variable Query Performance
  • From: Steve
• Re: Strangely Variable Query Performance
  • From: Steve
• Re: Strangely Variable Query Performance
  • From: Tom Lane
• Re: Strangely Variable Query Performance
  • From: Tom Lane
• Re: Strangely Variable Query Performance
  • From: Steve
• Re: Strangely Variable Query Performance
  • From: Tom Lane
• Re: Strangely Variable Query Performance
  • From: Steve
• Re: Strangely Variable Query Performance
  • From: Steve
• Re: Strangely Variable Query Performance
  • From: Tom Lane
• Re: Slow Postgresql server
  • From: Guido Neitzer
• Re: Strangely Variable Query Performance
  • From: Scott Marlowe
• Re: Strangely Variable Query Performance
  • From: Steve
• Re: Strangely Variable Query Performance
  • From: Steve
• Re: Strangely Variable Query Performance
  • From: Tom Lane
• Re: Slow Postgresql server
  • From: Jason Lustig
• Re: Strangely Variable Query Performance
  • From: Scott Marlowe
• Re: Strangely Variable Query Performance
  • From: Steve
• Re: Strangely Variable Query Performance
  • From: Tom Lane
• Strangely Variable Query Performance
  • From: Steve
• Re: Slow Postgresql server
  • From: Carlos Moreno
• Re: Equivalents in PostgreSQL of MySQL's "ENGINE=MEMORY" "MAX_ROWS=1000"
  • From: Robert Treat
• Re: Slow Postgresql server
  • From: Jeff Frost
• Re: Slow Postgresql server
  • From: Scott Marlowe
• Re: Question about memory allocations
  • From: Steve
• Re: Slow Postgresql server
  • From: Jeff Frost
• Re: Slow Postgresql server
  • From: Guido Neitzer
• Re: Slow Postgresql server
  • From: Ron
• Re: Slow Postgresql server
  • From: Guido Neitzer
• Re: Large objetcs performance
  • From: Merlin Moncure
• Re: Slow Postgresql server
  • From: Ron
• Re: Slow Postgresql server
  • From: Jeff Frost
• Re: Slow Postgresql server
  • From: Dennis Bjorklund
• Re: Question about memory allocations
  • From: Tom Lane
• Slow Postgresql server
  • From: Jason Lustig
• Question about memory allocations
  • From: Steve
• Re: Beginner Question
  • From: Jan de Visser
• Re: Do I need to rebuild php-pgsql for 8.2.3
  • From: Michael Dengler
• Re: Do I need to rebuild php-pgsql for 8.2.3
  • From: Devrim GÜNDÜZ
• Re: Do I need to rebuild php-pgsql for 8.2.3
  • From: Adam Rich
• Re: Do I need to rebuild php-pgsql for 8.2.3
  • From: Michael Dengler
• Long running transactions again ...
  • From: Tobias Brox
• Re: Do I need to rebuild php-pgsql for 8.2.3
  • From: Devrim GÜNDÜZ
• Re: Do I need to rebuild php-pgsql for 8.2.3
  • From: Guillaume Smet
• Do I need to rebuild php-pgsql for 8.2.3
  • From: Michael Dengler
• Re: join to view over custom aggregate seems like it should be faster
  • From: Tom Lane
• Re: join to view over custom aggregate seems like it should be faster
  • From: Merlin Moncure