Postgres Performance Date Index

• Thread Index

• Re: Improving Inner Join Performance
  • From: Andy
• Re: Improving Inner Join Performance
  • From: Michael Glaesemann
• Re: Improving Inner Join Performance
  • From: Andy
• Re: Slow query. Any way to speed up?
  • From: Tom Lane
• Re: Help in avoiding a query 'Warm-Up' period/shared buffer
  • From: Jim C. Nasby
• Re: Help in avoiding a query 'Warm-Up' period/shared buffer cache
  • From: Qingqing Zhou
• Re: Help in avoiding a query 'Warm-Up' period/shared buffer
  • From: David Lang
• Re: Help in avoiding a query 'Warm-Up' period/shared buffer cache
  • From: Mark Liberman
• Re: improving write performance for logging
  • From: Jim C. Nasby
• Slow query. Any way to speed up?
  • From: Patrick Hatcher
• Re: Help in avoiding a query 'Warm-Up' period/shared buffer cache
  • From: Qingqing Zhou
• Re: Improving Inner Join Performance
  • From: Frank Wiles
• Re: What's the best hardver for PostgreSQL 8.1?
  • From: Markus Schaber
• Improving Inner Join Performance
  • From: Andy
• Re: Invulnerable VACUUM process thrashing everything
  • From: Markus Schaber
• Re: improving write performance for logging application
  • From: Steve Eckmann
• Re: improving write performance for logging application
  • From: Steve Eckmann
• Help in avoiding a query 'Warm-Up' period/shared buffer cache
  • From: Mark Liberman
• Re: improving write performance for logging
  • From: Ian Westmacott
• Re: improving write performance for logging application
  • From: Kelly Burkhart
• Re: improving write performance for logging application
  • From: Tom Lane
• Re: improving write performance for logging
  • From: Ron
• Re: improving write performance for logging application
  • From: Steve Eckmann
• Re: improving write performance for logging application
  • From: Steve Eckmann
• Re: improving write performance for logging application
  • From: Steve Eckmann
• Re: improving write performance for logging application
  • From: Steve Eckmann
• Re: improving write performance for logging application
  • From: Ian Westmacott
• Avoiding cartesian product
  • From: Virag Saksena
• Re: improving write performance for logging application
  • From: dlang
• Re: improving write performance for logging application
  • From: Steinar H. Gunderson
• Re: improving write performance for logging application
  • From: Tom Lane
• improving write performance for logging application
  • From: Steve Eckmann
• Re: Materialize Subplan and push into inner index conditions
  • From: Tom Lane
• Materialize Subplan and push into inner index conditions
  • From: Jens-Wolfhard Schicke
• Re: CPU and RAM
  • From: Harry Jackson
• Re: Invulnerable VACUUM process thrashing everything
  • From: Tom Lane
• Re: Invulnerable VACUUM process thrashing everything
  • From: Russ Garrett
• Re: Invulnerable VACUUM process thrashing everything
  • From: Jeffrey W. Baker
• Re: Invulnerable VACUUM process thrashing everything
  • From: Ron
• Invulnerable VACUUM process thrashing everything
  • From: Jeffrey W. Baker
• Process executing COPY opens and reads every table on the system
  • From: Jeffrey W. Baker
• Re: How import big amounts of data?
  • From: Teemu Torma
• Re: How import big amounts of data?
  • From: Arnau
• Re: How import big amounts of data?
  • From: Teemu Torma
• Re: How import big amounts of data?
  • From: Ron
• Re: How import big amounts of data?
  • From: Dennis Bjorklund
• Re: How import big amounts of data?
  • From: Steinar H. Gunderson
• How import big amounts of data?
  • From: Arnau
• Re: What's the best hardver for PostgreSQL 8.1?
  • From: Ron
• Re: What's the best hardver for PostgreSQL 8.1?
  • From: Michael Stone
• Re: What's the best hardver for PostgreSQL 8.1?
  • From: Ron
• Re: What's the best hardver for PostgreSQL 8.1?
  • From: Luke Lonergan
• Re: What's the best hardver for PostgreSQL 8.1?
  • From: Luke Lonergan
• Re: What's the best hardver for PostgreSQL 8.1?
  • From: Michael Stone
• Re: Performance problems with 8.1.1 compared to 7.4.7
  • From: Frank Wiles
• Re: Performance problems with 8.1.1 compared to 7.4.7
  • From: Albert Cervera Areny
• Re: What's the best hardver for PostgreSQL 8.1?
  • From: Bruce Momjian
• Re: Performance problems with 8.1.1 compared to 7.4.7
  • From: Michael Fuhr
• Re: What's the best hardver for PostgreSQL 8.1?
  • From: Ron
• Performance problems with 8.1.1 compared to 7.4.7
  • From: Albert Cervera Areny
• Re: What's the best hardver for PostgreSQL 8.1?
  • From: Michael Stone
• Re: Bitmap indexes etc.
  • From: Ivan Voras
• Re: What's the best hardver for PostgreSQL 8.1?
  • From: Dawid Kuroczko
• Re: Performance hit on large row counts
  • From: Tom Lane
• Re: What's the best hardver for PostgreSQL 8.1?
  • From: David Lang
• Re: Performance hit on large row counts
  • From: David Scott
• Re: What's the best hardver for PostgreSQL 8.1?
  • From: Alex Turner
• Re: What's the best hardver for PostgreSQL 8.1?
  • From: Alex Turner
• Re: Bitmap indexes etc.
  • From: Tom Lane
• Bitmap indexes etc.
  • From: Ivan Voras
• Re: Performance hit on large row counts
  • From: Tom Lane
• Performance hit on large row counts
  • From: David Scott
• Re: What's the best hardver for PostgreSQL 8.1?
  • From: Luke Lonergan
• Re: What's the best hardver for PostgreSQL 8.1?
  • From: Benjamin Arai
• Re: What's the best hardver for PostgreSQL 8.1?
  • From: David Lang
• Re: What's the best hardver for PostgreSQL 8.1?
  • From: Alex Turner
• Fwd: vacuuming template0 gave ERROR
  • From: Gourish Singbal
• Re: What's the best hardver for PostgreSQL 8.1?
  • From: Luke Lonergan
• Re: What's the best hardver for PostgreSQL 8.1?
  • From: Benjamin Arai
• Re: What's the best hardver for PostgreSQL 8.1?
  • From: Michael Stone
• Re: What's the best hardver for PostgreSQL 8.1?
  • From: Bruno Wolff III
• Re: What's the best hardver for PostgreSQL 8.1?
  • From: Steinar H. Gunderson
• Re: What's the best hardver for PostgreSQL 8.1?
  • From: David Lang
• Re: What's the best hardver for PostgreSQL 8.1?
  • From: Joshua D. Drake
• Re: What's the best hardver for PostgreSQL 8.1?
  • From: William Yu
• Re: What's the best hardver for PostgreSQL 8.1?
  • From: Luke Lonergan
• Re: What's the best hardver for PostgreSQL 8.1?
  • From: David Lang
• Re: What's the best hardver for PostgreSQL 8.1?
  • From: Luke Lonergan
• Re: What's the best hardver for PostgreSQL 8.1?
  • From: Sander Steffann
• Re: What's the best hardver for PostgreSQL 8.1?
  • From: Ron
• Re: What's the best hardver for PostgreSQL 8.1?
  • From: William Yu
• Re: What's the best hardver for PostgreSQL 8.1?
  • From: Ron
• Re: What's the best hardver for PostgreSQL 8.1?
  • From: David Lang
• Re: What's the best hardver for PostgreSQL 8.1?
  • From: Joshua D. Drake
• Re: What's the best hardver for PostgreSQL 8.1?
  • From: Ron
• Re: What's the best hardver for PostgreSQL 8.1?
  • From: Frank Wiles
• Re: What's the best hardver for PostgreSQL 8.1?
  • From: Vivek Khera
• Re: Order by behaviour
  • From: Carlos Benkendorf
• Re: What's the best hardver for PostgreSQL 8.1?
  • From: Mark Kirkwood
• Re: What's the best hardver for PostgreSQL 8.1?
  • From: Vivek Khera
• Re: MySQL is faster than PgSQL but a large margin in
  • From: Vivek Khera
• Re: Order by behaviour
  • From: Tom Lane
• Re: DELETE, INSERT vs SELECT, UPDATE || INSERT
  • From: Tom Lane
• Re: Order by behaviour
  • From: Guido Neitzer
• Re: Order by behaviour
  • From: Kresimir Tonkovic
• Re: Order by behaviour
  • From: Carlos Benkendorf
• Re: Order by behaviour
  • From: Guido Neitzer
• Re: Order by behaviour
  • From: Carlos Benkendorf
• Re: Order by behaviour
  • From: Mario Weilguni
• Order by behaviour
  • From: Carlos Benkendorf
• DELETE, INSERT vs SELECT, UPDATE || INSERT
  • From: Anton Maksimenkov
• Re: CPU and RAM
  • From: Qingqing Zhou
• Re: What's the best hardver for PostgreSQL 8.1?
  • From: David Lang
• Re: What's the best hardver for PostgreSQL 8.1?
  • From: Juan Casero
• Re: CPU and RAM
  • From: Greg Stark
• Re: What's the best hardver for PostgreSQL 8.1?
  • From: David Lang
• Re: MySQL is faster than PgSQL but a large margin in
  • From: Juan Casero
• Re: What's the best hardver for PostgreSQL 8.1?
  • From: Juan Casero
• Re: ORDER BY costs
  • From: Carlos Benkendorf
• Re: effizient query with jdbc
  • From: Steve Peterson
• Re: effizient query with jdbc
  • From: Dave Cramer
• Re: ORDER BY costs
  • From: Carlos Benkendorf
• Re: MySQL is faster than PgSQL but a large margin in
  • From: Markus Schaber
• Re: Speed of different procedural language
  • From: Merlin Moncure
• Re: Wrong index used when ORDER BY LIMIT 1
  • From: Szűcs Gábor
• Re: CPU and RAM
  • From: Richard Huxton
• Re: MySQL is faster than PgSQL but a large margin in
  • From: Luke Lonergan
• Re: MySQL is faster than PgSQL but a large margin in
  • From: Luke Lonergan
• Re: MySQL is faster than PgSQL but a large margin in
  • From: Madison Kelly
• Re: MySQL is faster than PgSQL but a large margin in my
  • From: Madison Kelly
• Re: What's the best hardver for PostgreSQL 8.1?
  • From: Jignesh K. Shah
• Re: CPU and RAM
  • From: Qingqing Zhou
• Re: Speed of different procedural language
  • From: Tom Lane
• Re: What's the best hardver for PostgreSQL 8.1?
  • From: Tom Arthurs
• Re: MySQL is faster than PgSQL but a large margin in
  • From: Luke Lonergan
• Re: What's the best hardver for PostgreSQL 8.1?
  • From: Juan Casero
• Re: MySQL is faster than PgSQL but a large margin in my program... any ideas why?
  • From: Kevin Brown
• Re: Speed of different procedural language
  • From: Michael Fuhr
• Re: MySQL is faster than PgSQL but a large margin in my program... any ideas why?
  • From: Stephen Frost
• MySQL is faster than PgSQL but a large margin in my program... any ideas why?
  • From: Madison Kelly
• CPU and RAM
  • From: Harry Jackson
• Re: Speed of different procedural language
  • From: Steinar H. Gunderson
• Re: ORDER BY costs
  • From: Carlos Benkendorf
• Re: What's the best hardver for PostgreSQL 8.1?
  • From: William Yu
• Re: Speed of different procedural language
  • From: Michael Fuhr
• Re: Speed of different procedural language
  • From: Steinar H. Gunderson
• Re: Speed of different procedural language
  • From: Michael Fuhr
• Re: Speed of different procedural language
  • From: Merlin Moncure
• Re: ORDER BY costs
  • From: Tom Lane
• Re: Wrong index used when ORDER BY LIMIT 1
  • From: Tom Lane
• Re: Wrong index used when ORDER BY LIMIT 1
  • From: Michael Fuhr
• Re: Windows performance again
  • From: Merlin Moncure
• ORDER BY costs
  • From: Carlos Benkendorf
• Wrong index used when ORDER BY LIMIT 1
  • From: Szűcs Gábor
• Re: Windows performance again
  • From: Tom Lane
• Re: Windows performance again
  • From: Greg Stark
• Re: 2 phase commit: performance implications?
  • From: Andy Ballingall
• Re: [GENERAL] need help
  • From: Alban Medici (NetCentrex)
• Re: Speed of different procedural language
  • From: Steinar H. Gunderson
• Re: SAN/NAS options
  • From: Luke Lonergan
• Re: What's the best hardver for PostgreSQL 8.1?
  • From: Antal Attila
• Re: SAN/NAS options
  • From: Alex Stapleton
• Re: Windows performance again
  • From: Richard Huxton
• Windows performance again
  • From: Josep Maria Pinyol Fontseca
• Re: Simple Join
  • From: Mark Kirkwood
• Re: SAN/NAS options
  • From: Charles Sprickman
• Re: What's the best hardver for PostgreSQL 8.1?
  • From: David Lang
• Re: What's the best hardver for PostgreSQL 8.1?
  • From: Juan Casero
• Re: Any way to optimize GROUP BY queries?
  • From: Tom Lane
• Re: What's the best hardver for PostgreSQL 8.1?
  • From: Vivek Khera
• Re: What's the best hardver for PostgreSQL 8.1?
  • From: Jim C. Nasby
• Re: filesystem performance with lots of files
  • From: Jim C. Nasby
• Re: separate drives for WAL or pgdata files
  • From: Jim C. Nasby
• Re: High context switches occurring
  • From: Anjan Dave
• Re: Any way to optimize GROUP BY queries?
  • From: Jim C. Nasby
• Re: PostgreSQL and Ultrasparc T1
  • From: Jim C. Nasby
• Re: PostgreSQL and Ultrasparc T1
  • From: Jim C. Nasby
• Re: make bulk deletes faster?
  • From: Jim C. Nasby
• Re: Overriding the optimizer
  • From: Jim C. Nasby
• What's the best hardver for PostgreSQL 8.1?
  • From: Antal Attila
• Re: PostgreSQL and Ultrasparc T1
  • From: Jignesh K. Shah
• Re: PostgreSQL and Ultrasparc T1
  • From: Richard_D_Levine
• Re: Read only transactions - Commit or Rollback
  • From: Tom Lane
• Re: Read only transactions - Commit or Rollback
  • From: Markus Schaber
• Re: Read only transactions - Commit or Rollback
  • From: Greg Stark
• Re: Read only transactions - Commit or Rollback
  • From: Tom Lane
• Re: High context switches occurring
  • From: Tom Lane
• Re: PostgreSQL and Ultrasparc T1
  • From: David Lang
• Re: High context switches occurring
  • From: Oleg Bartunov
• Re: PostgreSQL and Ultrasparc T1
  • From: Alan Stange
• Re: PostgreSQL and Ultrasparc T1
  • From: David Lang
• Re: PostgreSQL and Ultrasparc T1
  • From: Alan Stange
• Re: 2 phase commit: performance implications?
  • From: David Roussel
• Re: High context switches occurring
  • From: Tom Lane
• Re: filesystem performance with lots of files
  • From: David Roussel
• Re: Read only transactions - Commit or Rollback
  • From: Nicolas Barbier
• Re: Read only transactions - Commit or Rollback
  • From: Markus Schaber
• Re: Read only transactions - Commit or Rollback
  • From: Andreas Seltenreich
• Re: Read only transactions - Commit or Rollback
  • From: Michael Riess
• Re: Read only transactions - Commit or Rollback
  • From: Markus Schaber
• Re: Read only transactions - Commit or Rollback
  • From: Nörder-Tuitje, Marcus
• Re: Read only transactions - Commit or Rollback
  • From: Grega Bremec
• unsubscribe
  • From: William Lai
• Re: Read only transactions - Commit or Rollback
  • From: Nörder-Tuitje, Marcus
• Read only transactions - Commit or Rollback
  • From: Markus Schaber
• Re: High context switches occurring
  • From: Jignesh K. Shah
• Re: separate drives for WAL or pgdata files
  • From: David Lang
• Re: separate drives for WAL or pgdata files
  • From: David Lang
• Re: High context switches occurring
  • From: Oleg Bartunov
• Re: PostgreSQL and Ultrasparc T1
  • From: Jignesh K. Shah
• Re: High context switches occurring
  • From: Juan Casero
• Re: High context switches occurring
  • From: Anjan Dave
• Re: PostgreSQL and Ultrasparc T1
  • From: Luke Lonergan
• Re: PostgreSQL and Ultrasparc T1
  • From: Luke Lonergan
• Re: SAN/NAS options
  • From: Anjan Dave
• Re: SAN/NAS options
  • From: Matthew Schumacher
• Re: PostgreSQL and Ultrasparc T1
  • From: Juan Casero
• Re: Is the optimizer choice right?
  • From: Greg Stark
• Re: Any way to optimize GROUP BY queries?
  • From: Greg Stark
• Is the optimizer choice right?
  • From: Carlos Benkendorf
• Re: PostgreSQL and Ultrasparc T1
  • From: Jignesh Shah
• separate drives for WAL or pgdata files
  • From: Anjan Dave
• Re: PostgreSQL and Ultrasparc T1
  • From: Luke Lonergan
• Re: PostgreSQL and Ultrasparc T1
  • From: Jignesh Shah
• Re: make bulk deletes faster?
  • From: James Klo
• Any way to optimize GROUP BY queries?
  • From: Cristian Prieto
• Re: PostgreSQL and Ultrasparc T1
  • From: Luke Lonergan
• Re: PostgreSQL and Ultrasparc T1
  • From: Anjan Dave
• Re: make bulk deletes faster?
  • From: Ang Chin Han
• Re: PostgreSQL and Ultrasparc T1
  • From: Jignesh K. Shah
• Re: make bulk deletes faster?
  • From: Mitch Skinner
• Re: make bulk deletes faster?
  • From: James Klo
• Re: PostgreSQL and Ultrasparc T1
  • From: Luke Lonergan
• Re: PostgreSQL and Ultrasparc T1
  • From: Scott Marlowe
• Re: make bulk deletes faster?
  • From: Michael Fuhr
• Re: Should Oracle outperform PostgreSQL on a complex
  • From: Simon Riggs
• Re: Should Oracle outperform PostgreSQL on a complex
  • From: Simon Riggs
• Re: Should Oracle outperform PostgreSQL on a complex
  • From: Mark Kirkwood
• Re: Should Oracle outperform PostgreSQL on a complex
  • From: Mark Kirkwood
• Re: Should Oracle outperform PostgreSQL on a complex
  • From: Mark Kirkwood
• Re: Should Oracle outperform PostgreSQL on a complex
  • From: Simon Riggs
• Re: PostgreSQL and Ultrasparc T1
  • From: Christopher Petrilli
• PostgreSQL and Ultrasparc T1
  • From: Juan Casero
• Re: Should Oracle outperform PostgreSQL on a complex
  • From: Simon Riggs
• Re: Should Oracle outperform PostgreSQL on a complex
  • From: Simon Riggs
• Re: Should Oracle outperform PostgreSQL on a complex
  • From: Greg Stark
• make bulk deletes faster?
  • From: James Klo
• Re: Should Oracle outperform PostgreSQL on a complex
  • From: Mark Kirkwood
• Re: PostgreSQL performance question. [OT]
  • From: Steinar H. Gunderson
• Re: PostgreSQL performance question.
  • From: Harry Jackson
• Re: Should Oracle outperform PostgreSQL on a complex
  • From: Mark Kirkwood
• Speed of different procedural language
  • From: Ben Trewern
• Re: Should Oracle outperform PostgreSQL on a complex
  • From: Luke Lonergan
• Re: Should Oracle outperform PostgreSQL on a complex
  • From: Bruce Momjian
• Re: Should Oracle outperform PostgreSQL on a complex
  • From: Tom Lane
• Re: Should Oracle outperform PostgreSQL on a complex
  • From: Tom Lane
• Re: Should Oracle outperform PostgreSQL on a complex
  • From: Tom Lane
• Re: Should Oracle outperform PostgreSQL on a complex
  • From: Bruce Momjian
• Re: Simple Join
  • From: Bruce Momjian
• Re: Overriding the optimizer
  • From: Jaime Casanova
• Re: Should Oracle outperform PostgreSQL on a complex
  • From: Simon Riggs
• Re: Overriding the optimizer
  • From: David Lang
• Re: Overriding the optimizer
  • From: Tom Lane
• Re: Should Oracle outperform PostgreSQL on a complex
  • From: Mark Kirkwood
• Re: Should Oracle outperform PostgreSQL on a complex
  • From: Bruce Momjian
• Re: How much expensive are row level statistics?
  • From: Bruce Momjian
• Re: Overriding the optimizer
  • From: Kyle Cordes
• Re: SAN/NAS options
  • From: Michael Stone
• Re: SAN/NAS options
  • From: Jim C. Nasby
• Re: SAN/NAS options
  • From: Michael Stone
• Re: SAN/NAS options
  • From: Mark Kirkwood
• Re: Overriding the optimizer
  • From: Jim C. Nasby
• Re: Overriding the optimizer
  • From: Jim C. Nasby
• Re: Overriding the optimizer
  • From: Jim C. Nasby
• Re: SAN/NAS options
  • From: Jim C. Nasby
• Re: SAN/NAS options
  • From: Jim C. Nasby
• Re: Lots of postmaster processes (fwd)
  • From: Jim C. Nasby
• Re: Simple Join
  • From: Mark Kirkwood
• Re: 8.1 - pg_autovacuum question
  • From: Alvaro Herrera
• 8.1 - pg_autovacuum question
  • From: Chris Hoover
• Re: Overriding the optimizer
  • From: Mitch Skinner
• Re: Overriding the optimizer
  • From: Craig A. James
• Re: ALTER TABLE SET TABLESPACE and pg_toast
  • From: Tom Lane
• Re: Overriding the optimizer
  • From: Tomasz Rybak
• Re: Overriding the optimizer
  • From: Jaime Casanova
• Re: How much expensive are row level statistics?
  • From: Merlin Moncure
• Re: Crashing DB or Server?
  • From: Csaba Nagy
• ALTER TABLE SET TABLESPACE and pg_toast
  • From: PostgreSQL
• Re: Overriding the optimizer
  • From: Kyle Cordes
• Re: Crashing DB or Server?
  • From: Moritz Bayer
• Re: Crashing DB or Server?
  • From: Harry Jackson
• Crashing DB or Server?
  • From: Moritz Bayer
• Re: How much expensive are row level statistics?
  • From: Simon Riggs
• Re: Overriding the optimizer
  • From: Bruno Wolff III
• Re: Overriding the optimizer
  • From: Kevin Brown
• Re: How much expensive are row level statistics?
  • From: Kevin Brown
• Re: Overriding the optimizer
  • From: Craig A. James
• Re: Overriding the optimizer
  • From: Kevin Brown
• Re: Overriding the optimizer
  • From: Kevin Brown
• Re: Overriding the optimizer
  • From: David Lang
• Re: Overriding the optimizer
  • From: Jaime Casanova
• Re: Overriding the optimizer
  • From: Jaime Casanova
• Re: Simple Join
  • From: David Lang
• Re: Overriding the optimizer
  • From: David Lang
• Re: Overriding the optimizer
  • From: Craig A. James
• Re: Overriding the optimizer
  • From: Craig A. James
• Re: Overriding the optimizer
  • From: Christopher Kings-Lynne
• Re: Overriding the optimizer
  • From: Mark Kirkwood
• Re: Overriding the optimizer
  • From: Craig A. James
• Re: Overriding the optimizer
  • From: Craig A. James
• Re: Overriding the optimizer
  • From: Craig A. James
• Re: Overriding the optimizer
  • From: Craig A. James
• Re: Overriding the optimizer
  • From: Christopher Kings-Lynne
• Re: Overriding the optimizer
  • From: Mark Kirkwood
• Re: Overriding the optimizer
  • From: Craig A. James
• Re: Overriding the optimizer
  • From: Christopher Kings-Lynne
• Re: Overriding the optimizer
  • From: Craig A. James
• Re: Overriding the optimizer
  • From: Craig A. James
• Re: Overriding the optimizer
  • From: Christopher Kings-Lynne
• Re: Overriding the optimizer
  • From: Jaime Casanova
• Re: Overriding the optimizer
  • From: Christopher Kings-Lynne
• Re: Overriding the optimizer
  • From: Tom Lane
• Re: How much expensive are row level statistics?
  • From: Tom Lane
• Re: How much expensive are row level statistics?
  • From: Michael Fuhr
• Overriding the optimizer
  • From: Craig A. James
• Re: SAN/NAS options
  • From: Luke Lonergan
• Re: SAN/NAS options
  • From: Anjan Dave
• Re: Simple Join
  • From: Mark Kirkwood
• effizient query with jdbc
  • From: johannesbuehler
• Re: [postgis-users] Is my query planner failing me,or vice versa?
  • From: Mark Cave-Ayland
• Re: [postgis-users] Is my query planner failing me, or vice versa?
  • From: Gregory S. Williamson
• Re: [postgis-users] Is my query planner failing me, or vice versa?
  • From: Markus Schaber
• Re: Simple Join
  • From: Mitch Skinner
• Re: Simple Join
  • From: Mark Kirkwood
• Re: Simple Join
  • From: Kevin Brown
• Re: Simple Join
  • From: Kevin Brown
• effizient query with jdbc
  • From: Johannes Bühler
• Re: Simple Join
  • From: Mitchell Skinner
• effizient query with jdbc
  • From: Bühler, Johannes
• Re: [postgis-users] Is my query planner failing me, or vice versa?
  • From: Tom Lane
• Re: PostgreSQL performance question.
  • From: Gavin Sherry
• Re: PostgreSQL performance question.
  • From: Christopher Kings-Lynne
• PostgreSQL performance question.
  • From: Harry Jackson
• Re: Simple Join
  • From: Mark Kirkwood
• effizient query with jdbc
  • From: Bühler, Johannes
• Re: [postgis-users] Is my query planner failing me, or vice versa?
  • From: Gregory S. Williamson
• Re: Simple Join
  • From: Kevin Brown
• Re: Simple Join
  • From: Kevin Brown
• Re: Simple Join
  • From: Steinar H. Gunderson
• Re: Simple Join
  • From: Mark Kirkwood
• Re: Simple Join
  • From: Jaime Casanova
• Re: Simple Join
  • From: Kevin Brown
• Re: Simple Join
  • From: Tom Lane
• Re: Auto-tuning a VIEW?
  • From: PFC
• Simple Join
  • From: Kevin Brown
• Re: Auto-tuning a VIEW?
  • From: Zoltan Boszormenyi
• Re: Auto-tuning a VIEW?
  • From: PFC
• Auto-tuning a VIEW?
  • From: Zoltan Boszormenyi
• Re: SAN/NAS options
  • From: Michael Stone
• Re: SAN/NAS options
  • From: Andrew Rawnsley
• Re: Convert IN sublink to join
  • From: Tom Lane
• Convert IN sublink to join
  • From: francisco.santos
• Re: SAN/NAS options
  • From: Mark Kirkwood
• Re: SAN/NAS options
  • From: Luke Lonergan
• SAN/NAS options
  • From: Charles Sprickman
• SAN/NAS options
  • From: Charles Sprickman
• Re: Should Oracle outperform PostgreSQL on a complex
  • From: Luke Lonergan
• Re: Table Partitions / Partial Indexes
  • From: Mike C
• Re: Should Oracle outperform PostgreSQL on a complex
  • From: Simon Riggs
• Re: Should Oracle outperform PostgreSQL on a complex
  • From: Tomeh, Husam
• Re: Table Partitions / Partial Indexes
  • From: Simon Riggs
• Re: query from partitions
  • From: Simon Riggs
• Lots of postmaster processes (fwd)
  • From: Ameet Kini
• Re: query from partitions
  • From: Ключников А.С.
• Re: Small table or partial index?
  • From: Francisco Reyes
• Re: query from partitions
  • From: Steinar H. Gunderson
• Re: query from partitions
  • From: Richard Huxton
• query from partitions
  • From: Ключников А.С.
• Re: partitioning
  • From: Marc Cousin
• Re: partitioning
  • From: Pandurangan R S
• Re: partitioning
  • From: Pandurangan R S
• partitioning
  • From: Marc Cousin
• Re: How much expensive are row level statistics?
  • From: Tom Lane
• Re: How much expensive are row level statistics?
  • From: Michael Fuhr
• Re: opinion on disk speed
  • From: J. Andrew Rogers
• Re: opinion on disk speed
  • From: Scott Marlowe
• Re: How much expensive are row level statistics?
  • From: Tom Lane
• Re: Joining 2 tables with 300 million rows
  • From: Manfred Koizar
• Re: Small table or partial index?
  • From: Jim C. Nasby
• Re: opinion on disk speed
  • From: Vivek Khera
• Re: opinion on disk speed
  • From: J. Andrew Rogers
• Re: opinion on disk speed
  • From: Vivek Khera
• Re: How much expensive are row level statistics?
  • From: Michael Fuhr
• Re: How much expensive are row level statistics?
  • From: Michael Fuhr
• Re: opinion on disk speed
  • From: Vivek Khera
• Re: How much expensive are row level statistics?
  • From: Merlin Moncure
• Re: Should Oracle outperform PostgreSQL on a complex
  • From: Luke Lonergan
• Re: How much expensive are row level statistics?
  • From: Alvaro Herrera
• Re: Very slow queries - please help
  • From: Bealach-na Bo
• Re: 7.4.7 vs. 8.1
  • From: Steinar H. Gunderson
• 7.4.7 vs. 8.1
  • From: Szabolcs BALLA
• 2 phase commit: performance implications?
  • From: Andy Ballingall
• Re: Is RAID10 the best choice?
  • From: Alex Turner
• Re: Table Partitions / Partial Indexes
  • From: Mike C
• Re: Table Partitions / Partial Indexes
  • From: Tom Lane
• Table Partitions / Partial Indexes
  • From: Mike C
• Re: Should Oracle outperform PostgreSQL on a complex
  • From: Luke Lonergan
• Re: Should Oracle outperform PostgreSQL on a complex multidimensional query?
  • From: Tom Lane
• Re: Join the same row
  • From: Tom Lane
• Re: How much expensive are row level statistics?
  • From: Michael Fuhr
• How much expensive are row level statistics?
  • From: Carlos Benkendorf
• Re: Bitmasks
  • From: Greg Stark
• Bitmasks
  • From: Ivan Voras
• Re: Queries taking ages in PG 8.1, have been much faster in PG<=8.0
  • From: Manfred Koizar
• Re: Clustered tables and seqscan disabled
  • From: Tom Lane
• Re: Executing a shell command from a PG function
  • From: Yves Vindevogel
• Re: Executing a shell command from a PG function
  • From: Michael Fuhr
• Re: Executing a shell command from a PG function
  • From: Jaime Casanova
• Executing a shell command from a PG function
  • From: Yves Vindevogel
• Clustered tables and seqscan disabled
  • From: Henrique Engelmann
• Is RAID10 the best choice?
  • From: Carlos Benkendorf
• Re: Query not using index
  • From: Kaloyan Iliev
• Re: Query not using index
  • From: Kaloyan Iliev
• Re: opinion on disk speed
  • From: Frank Wiles
• Re: opinion on disk speed
  • From: Andreas Pflug
• Re: opinion on disk speed
  • From: Frank Wiles
• Re: opinion on disk speed
  • From: Frank Wiles
• Re: Joining 2 tables with 300 million rows
  • From: Jeff Trout
• Re: Query not using index
  • From: Jaime Casanova
• Re: opinion on disk speed
  • From: Jeremy Haile
• Query not using index
  • From: Kaloyan Iliev
• Re: opinion on disk speed
  • From: David Lang
• Re: Disk tests for a new database server
  • From: Rory Campbell-Lange
• Re: Joining 2 tables with 300 million rows
  • From: Amit V Shah
• Re: Joining 2 tables with 300 million rows
  • From: Dmitri Bichko
• Re: opinion on disk speed
  • From: Jeffrey W. Baker
• Re: Disk tests for a new database server
  • From: Steve Poe
• Re: opinion on disk speed
  • From: Scott Marlowe
• Joining 2 tables with 300 million rows
  • From: Amit V Shah
• slow COMMITs
  • From: Evgeny Gridasov
• Re: opinion on disk speed
  • From: Dave Page
• opinion on disk speed
  • From: Vivek Khera
• Should Oracle outperform PostgreSQL on a complex multidimensional query?
  • From: Pål Stenslet
• Re: Performance degradation after successive UPDATE's
  • From: Assaf Yaari
• Re: INSERTs becoming slower and slower
  • From: Matteo Beccati
• Re: view of view
  • From: Rich Doughty
• Re: view of view
  • From: Merlin Moncure
• Disk tests for a new database server
  • From: Rory Campbell-Lange
• Re: LVM and Postgres
  • From: Rory Campbell-Lange
• Re: INSERTs becoming slower and slower
  • From: Christopher Kings-Lynne
• INSERTs becoming slower and slower
  • From: Nörder-Tuitje, Marcus
• view of view
  • From: Keith Worthington
• Re: Performance degradation after successive UPDATE's
  • From: Bruno Wolff III
• Re: Join the same row
  • From: Richard Huxton
• Re: Join the same row
  • From: Edison Azzi
• Re: First query is slow, subsequent queries fast
  • From: Stephan Vollmer
• Re: High context switches occurring
  • From: Scott Marlowe
• Re: High context switches occurring
  • From: Anjan Dave
• Re: postgresql performance tuning
  • From: Vivek Khera
• Re: Performance degradation after successive UPDATE's
  • From: Assaf Yaari
• Re: First query is slow, subsequent queries fast
  • From: Oleg Bartunov
• First query is slow, subsequent queries fast
  • From: Stephan Vollmer
• table partitioning: effects of many sub-tables (was COPY too slow...)
  • From: Rick Schumeyer
• Re: Join the same row
  • From: Richard Huxton
• Re: TSearch2 vs. Apache Lucene
  • From: Michael Riess
• Re: TSearch2 vs. Apache Lucene
  • From: Christopher Kings-Lynne
• Re: TSearch2 vs. Apache Lucene
  • From: Michael Riess
• Re: High context switches occurring
  • From: Tatsuo Ishii
• Re: Query Fails with error calloc - Cannot alocate memory
  • From: Neil Conway
• Re: High context switches occurring
  • From: Tom Lane
• Re: Effects of cascading references in foreign keys
  • From: Bruce Momjian
• Re: High context switches occurring
  • From: Bruce Momjian
• Re: Query Fails with error calloc - Cannot alocate memory
  • From: Christopher Kings-Lynne
• Re: LVM and Postgres
  • From: Kevin Brown
• Re: TSearch2 vs. Apache Lucene
  • From: Christopher Kings-Lynne
• Re: LVM and Postgres
  • From: Michael Stone
• Re: LVM and Postgres
  • From: Alex Turner
• Re: LVM and Postgres
  • From: Michael Stone
• Re: postgresql performance tuning
  • From: Michael Stone
• Re: High context switches occurring
  • From: Tom Lane
• Re: postgresql performance tuning
  • From: Ameet Kini
• Re: two disks - best way to use them?
  • From: David Lang
• Re: Context switching and Xeon processors
  • From: Steinar H. Gunderson
• Re: Context switching and Xeon processors
  • From: Brandon Metcalf
• Re: postgresql performance tuning
  • From: Alan Stange
• Re: Context switching and Xeon processors
  • From: Tom Lane
• Re: LVM and Postgres
  • From: Rory Campbell-Lange
• Re: Missed index opportunity for outer join?
  • From: Ron Mayer
• Re: Missed index opportunity for outer join?
  • From: Tom Lane
• Re: postgresql performance tuning
  • From: Tom Lane
• Context switching and Xeon processors
  • From: Brandon Metcalf
• Re: Missed index opportunity for outer join?
  • From: Ron Mayer
• Re: postgresql performance tuning
  • From: Michael Riess
• Re: postgresql performance tuning
  • From: Alan Stange
• Re: Can this query go faster???
  • From: Bruno Wolff III
• Re: Performance degradation after successive UPDATE's
  • From: Bruno Wolff III
• Re: TSearch2 vs. Apache Lucene
  • From: Russell Garrett
• Re: Missed index opportunity for outer join?
  • From: Tom Lane
• Join the same row
  • From: Edison Azzi
• Re: LVM and Postgres
  • From: August Zajonc
• Re: Missed index opportunity for outer join?
  • From: Ron Mayer
• Re: postgresql performance tuning
  • From: Vivek Khera
• Re: High context switches occurring
  • From: Vivek Khera
• postgresql performance tuning
  • From: Ameet Kini
• Re: High context switches occurring
  • From: Anjan Dave
• Re: postgresql performance tuning
  • From: Vivek Khera
• Re: TSearch2 vs. Apache Lucene
  • From: Bruce Momjian
• Re: TSearch2 vs. Apache Lucene
  • From: Michael Riess
• Re: postgresql performance tuning
  • From: Tom Lane
• Re: TSearch2 vs. Apache Lucene
  • From: Tom Lane
• Re: Memory Leakage Problem
  • From: Scott Marlowe
• postgresql performance tuning
  • From: Ameet Kini
• Re: TSearch2 vs. Apache Lucene
  • From: Bruce Momjian
• Re: TSearch2 vs. Apache Lucene
  • From: Oleg Bartunov
• Re: TSearch2 vs. Apache Lucene
  • From: Michael Riess
• Re: Missed index opportunity for outer join?
  • From: Tom Lane
• TSearch2 vs. Apache Lucene
  • From: Joshua Kramer
• Re: 8.1 count(*) distinct: IndexScan/SeqScan
  • From: Pailloncy Jean-Gerard
• Re: two disks - best way to use them?
  • From: Thomas Harold
• Re: Memory Leakage Problem
  • From: Tom Lane
• Re: Can this query go faster???
  • From: Merlin Moncure
• Re: Can this query go faster???
  • From: Ron
• Re: Can this query go faster???
  • From: Csaba Nagy
• Re: Performance degradation after successive UPDATE's
  • From: Jan Wieck
• Re: Can this query go faster???
  • From: Tino Wildenhain
• Re: Can this query go faster???
  • From: Joost Kraaijeveld
• Re: BLCKSZ
  • From: David Lang
• Re: Can this query go faster???
  • From: Tino Wildenhain
• Re: Can this query go faster???
  • From: Joost Kraaijeveld
• Re: BLCKSZ
  • From: Steinar H. Gunderson
• Re: BLCKSZ
  • From: Olleg
• Re: Can this query go faster???
  • From: Tino Wildenhain
• Re: Can this query go faster???
  • From: Joost Kraaijeveld
• Re: Can this query go faster???
  • From: Markus Wollny
• Re: Can this query go faster???
  • From: Csaba Nagy
• Re: Performance degradation after successive UPDATE's
  • From: Pandurangan R S
• Re: Can this query go faster???
  • From: Michael Riess
• Can this query go faster???
  • From: Joost Kraaijeveld
• need help (not anymore)
  • From: Jenny
• LVM and Postgres
  • From: Rory Campbell-Lange
• Memory Leakage Problem
  • From: Kathy Lo
• Re: Performance degradation after successive UPDATE's
  • From: Assaf Yaari
• Re: [GENERAL] need help
  • From: Tino Wildenhain
• need help
  • From: Jenny
• Re: two disks - best way to use them?
  • From: Ron
• Re: two disks - best way to use them?
  • From: Thomas Harold
• Re: BLCKSZ
  • From: Tom Lane
• Re: two disks - best way to use them?
  • From: David Lang
• Re: 15,000 tables - next step
  • From: Jan Wieck
• Re: BLCKSZ
  • From: Ron
• Re: BLCKSZ
  • From: Alvaro Herrera
• Re: Missed index opportunity for outer join?
  • From: rm_pg
• Re: Missed index opportunity for outer join?
  • From: Tom Lane
• Re: BLCKSZ
  • From: Olleg
• Missed index opportunity for outer join?
  • From: rm_pg
• Re: Performance degradation after successive UPDATE's
  • From: Bruno Wolff III
• Performance degradation after successive UPDATE's
  • From: Assaf Yaari
• Re: Best hardware
  • From: Mirjam (sent by Nabble.com)
• Re: two disks - best way to use them?
  • From: Thomas Harold
• Re: two disks - best way to use them?
  • From: David Lang
• Re: two disks - best way to use them?
  • From: Thomas Harold
• Re: Queries taking ages in PG 8.1, have been much faster in PG<=8.0
  • From: Markus Wollny
• Re: Queries taking ages in PG 8.1, have been much faster in PG<=8.0
  • From: Markus Wollny
• Re: Queries taking ages in PG 8.1, have been much faster in PG<=8.0
  • From: Tom Lane
• Re: BLCKSZ
  • From: Tom Lane
• Re: Queries taking ages in PG 8.1, have been much faster in PG<=8.0
  • From: Markus Wollny
• Re: Queries taking ages in PG 8.1, have been much faster in PG<=8.0
  • From: Tom Lane
• Re: two disks - best way to use them?
  • From: Olleg Samoylov
• BLCKSZ
  • From: Olleg Samoylov
• Re: Queries taking ages in PG 8.1, have been much faster in PG<=8.0
  • From: Markus Wollny
• Query Fails with error calloc - Cannot alocate memory
  • From: Howard Oblowitz
• Dividing up a single 250GB RAID10 server for postgres
  • From: Rory Campbell-Lange
• Re: Faster db architecture for a twisted table.
  • From: Klint Gore
• Re: Queries taking ages in PG 8.1, have been much faster in PG<=8.0
  • From: Tom Lane
• Re: Queries taking ages in PG 8.1, have been much faster in PG<=8.0
  • From: Markus Wollny
• Re: Faster db architecture for a twisted table.
  • From: Andreas Pflug
• Re: 15,000 tables - next step
  • From: Michael Riess
• Re: 15,000 tables - next step
  • From: William Yu
• Re: Very slow queries - please help
  • From: Thomas F. O'Connell
• Re: Faster db architecture for a twisted table.
  • From: Hélder M . Vieira
• Re: Database restore speed
  • From: David Lang
• Re: Faster db architecture for a twisted table.
  • From: Mitchell Skinner
• Re: Faster db architecture for a twisted table.
  • From: Andreas Pflug
• Re: Database restore speed
  • From: Mitch Skinner
• Faster db architecture for a twisted table.
  • From: Rodrigo Madera
• Re: Database restore speed
  • From: Luke Lonergan
• Re: Database restore speed
  • From: Tom Lane
• Re: Database restore speed
  • From: Luke Lonergan
• Re: 15,000 tables - next step
  • From: Jan Wieck
• Re: 15,000 tables - next step
  • From: Jaime Casanova
• Re: 15,000 tables - next step
  • From: Michael Riess
• Re: 15,000 tables - next step
  • From: Alvaro Herrera
• Re: 15,000 tables - next step
  • From: Michael Riess
• Re: 15,000 tables - next step
  • From: Jan Wieck
• Re: Database restore speed
  • From: Simon Riggs
• Re: Database restore speed
  • From: David Lang
• Re: Database restore speed
  • From: David Lang
• Re: Database restore speed
  • From: David Lang
• Re: Database restore speed
  • From: David Lang
• Re: Database restore speed
  • From: David Lang
• Re: Database restore speed
  • From: Luke Lonergan
• Re: Database restore speed
  • From: Mitch Skinner
• Small table or partial index?
  • From: Francisco Reyes
• Re: Database restore speed
  • From: Luke Lonergan
• 15,000 tables - next step
  • From: Michael Riess
• Re: Database restore speed
  • From: Tom Lane
• Re: 15,000 tables
  • From: Francisco Reyes
• Re: Database restore speed
  • From: Michael Stone
• Re: Database restore speed
  • From: Luke Lonergan
• Re: Database restore speed
  • From: Luke Lonergan
• Re: Database restore speed
  • From: Stephen Frost
• Re: 15,000 tables
  • From: Andrew Sullivan
• Re: Network permormance under windows
  • From: Josep Maria Pinyol Fontseca
• Re: Database restore speed
  • From: Luke Lonergan
• Re: Network permormance under windows
  • From: Qingqing Zhou
• Re: Network permormance under windows
  • From: me
• Re: Database restore speed
  • From: Stephen Frost
• Re: two disks - best way to use them?
  • From: Ron
• Re: Network permormance under windows
  • From: Josep Maria Pinyol Fontseca
• two disks - best way to use them?
  • From: Rick Schumeyer
• Re: Open request for benchmarking input (fwd)
  • From: Qingqing Zhou
• Re: pg_dump slow
  • From: Merlin Moncure
• Re: pg_dump slow
  • From: Merlin Moncure
• Re: Network permormance under windows
  • From: Merlin Moncure
• Network permormance under windows
  • From: Teracat
• Re: 15,000 tables
  • From: Jan Wieck
• Re: 15,000 tables
  • From: Alex Stapleton
• Re: 15,000 tables
  • From: Alex Stapleton
• Re: COPY into table too slow with index: now an I/O
  • From: Michael Stone
• Re: 15,000 tables
  • From: Michael Stone
• Re: 15,000 tables
  • From: Ron
• Re: Database restore speed
  • From: Luke Lonergan
• Re: filesystem performance with lots of files
  • From: David Lang
• Re: Database restore speed
  • From: David Lang
• Re: 15,000 tables
  • From: David Lang
• Re: filesystem performance with lots of files
  • From: Qingqing Zhou
• Re: Open request for benchmarking input (fwd)
  • From: David Lang
• Re: filesystem performance with lots of files
  • From: David Lang
• Re: Database restore speed
  • From: Luke Lonergan
• Re: COPY into table too slow with index: now an I/O
  • From: Luke Lonergan
• Re: 15,000 tables
  • From: Craig A. James
• Re: COPY into table too slow with index: now an I/O question
  • From: Rick Schumeyer
• Re: COPY into table too slow with index: now an I/O
  • From: Tom Lane
• Database restore speed
  • From: Steve Oualline
• Re: COPY into table too slow with index: now an I/O
  • From: Luke Lonergan
• Re: COPY into table too slow with index: now an I/O question
  • From: Rick Schumeyer
• Re: 15,000 tables
  • From: Alvaro Herrera
• Re: 15,000 tables
  • From: Scott Marlowe
• Re: 15,000 tables
  • From: Merlin Moncure
• Re: 15,000 tables
  • From: Jaime Casanova
• Re: 15,000 tables
  • From: Michael Riess
• Re: Insert performance slows down in large batch
  • From: Tom Lane
• Re: 15,000 tables
  • From: Gavin M. Roy
• Insert performance slows down in large batch
  • From: Jeremy Haile
• Re: 15,000 tables
  • From: Tom Lane
• Re: 15,000 tables
  • From: Gavin M. Roy
• Re: 15,000 tables
  • From: Ron
• Re: 15,000 tables
  • From: Tino Wildenhain
• COPY into table too slow with index
  • From: Rick Schumeyer
• Re: 15,000 tables
  • From: Gavin M. Roy
• Re: 15,000 tables
  • From: Chris Browne
• Re: filesystem performance with lots of files
  • From: Qingqing Zhou
• pg_stat* values ...
  • From: Marc G. Fournier
• Re: 15,000 tables
  • From: me
• Re: 15,000 tables
  • From: Michael Riess
• Re: Queries taking ages in PG 8.1, have been much faster in PG<=8.0
  • From: Tom Lane