Postgres Performance Date Index

• Thread Index

• PG planning randomly ?
  • From: Laurent Raufaste
• Re: response time when querying via JDBC and via psql differs
  • From: valgog
• multi-threaded pgloader needs your tests
  • From: Dimitri Fontaine
• Re: when is a DELETE FK trigger planned?
  • From: Tom Lane
• Re: Weird issue with planner choosing seq scan
  • From: Sean Leach
• Re: Weird issue with planner choosing seq scan
  • From: Stephen Denne
• Re: Weird issue with planner choosing seq scan
  • From: Stephen Denne
• Re: Weird issue with planner choosing seq scan
  • From: Sean Leach
• Re: Weird issue with planner choosing seq scan
  • From: Stephen Denne
• when is a DELETE FK trigger planned?
  • From: Andrew Lazarus
• Re: LISTEN / NOTIFY performance in 8.3
  • From: Joel Stevenson
• Re: LISTEN / NOTIFY performance in 8.3
  • From: Tom Lane
• Re: LISTEN / NOTIFY performance in 8.3
  • From: Joel Stevenson
• Re: LISTEN / NOTIFY performance in 8.3
  • From: Tom Lane
• Re: LISTEN / NOTIFY performance in 8.3
  • From: Joel Stevenson
• Re: LISTEN / NOTIFY performance in 8.3
  • From: Joel Stevenson
• Re: Q on views and performance
  • From: Matthew
• Re: Q on views and performance
  • From: Kynn Jones
• Re: Weird issue with planner choosing seq scan
  • From: Matthew
• Re: Weird issue with planner choosing seq scan
  • From: Sean Leach
• Re: response time when querying via JDBC and via psql differs
  • From: Nikolas Everett
• Re: Q on views and performance
  • From: Matthew
• Re: Q on views and performance
  • From: Matthew
• Re: CORRECTION to msg 'loading same instance of dump to two different servers simultaneously'
  • From: Matthew
• Re: response time when querying via JDBC and via psql differs
  • From: Markus Bertheau
• response time when querying via JDBC and via psql differs
  • From: Pavel Rotek
• Re: LISTEN / NOTIFY performance in 8.3
  • From: Joel Stevenson
• Re: Weird issue with planner choosing seq scan
  • From: Scott Marlowe
• Re: Weird issue with planner choosing seq scan
  • From: Sean Leach
• Re: Weird issue with planner choosing seq scan
  • From: Scott Marlowe
• Re: Weird issue with planner choosing seq scan
  • From: Sean Leach
• Re: Weird issue with planner choosing seq scan
  • From: Stephen Denne
• Re: Weird issue with planner choosing seq scan
  • From: Sean Leach
• Re: Weird issue with planner choosing seq scan
  • From: Tom Lane
• Re: LISTEN / NOTIFY performance in 8.3
  • From: Tom Lane
• Re: Weird issue with planner choosing seq scan
  • From: Sean Leach
• Re: Weird issue with planner choosing seq scan
  • From: Tom Lane
• Weird issue with planner choosing seq scan
  • From: Sean Leach
• Re: LISTEN / NOTIFY performance in 8.3
  • From: Joel Stevenson
• Re: LISTEN / NOTIFY performance in 8.3
  • From: Tom Lane
• LISTEN / NOTIFY performance in 8.3
  • From: Joel Stevenson
• Re: Q on views and performance
  • From: Dean Gibson (DB Administrator)
• Re: Q on views and performance
  • From: Dean Gibson (DB Administrator)
• Re: Q on views and performance
  • From: Kynn Jones
• Re: Q on views and performance
  • From: Dean Gibson (DB Administrator)
• Re: Q on views and performance
  • From: Dean Gibson (DB Administrator)
• Re: Q on views and performance
  • From: Robins Tharakan
• Re: Q on views and performance
  • From: Kynn Jones
• Re: Q on views and performance
  • From: Kynn Jones
• Re: store A LOT of 3-tuples for comparisons
  • From: Moritz Onken
• Re: store A LOT of 3-tuples for comparisons
  • From: Shane Ambler
• Re: Q on views and performance
  • From: Dean Gibson (DB Administrator)
• Q on views and performance
  • From: Kynn Jones
• loading same instance of dump to two different servers simultaneously?
  • From: Susan Russo
• CORRECTION to msg 'loading same instance of dump to two different servers simultaneously'
  • From: Susan Russo
• Re: store A LOT of 3-tuples for comparisons
  • From: Matthew
• store A LOT of 3-tuples for comparisons
  • From: Moritz Onken
• Re: 7 hrs for a pg_restore?
  • From: Guillaume Cottenceau
• Re: 4s query want to run faster
  • From: Mark Kirkwood
• config settings, was: 4s query want to run faster
  • From: Scott Marlowe
• Re: 4s query want to run faster
  • From: Dave Cramer
• Re: 4s query want to run faster
  • From: Scott Marlowe
• Re: 4s query want to run faster
  • From: Mark Kirkwood
• Re: 4s query want to run faster
  • From: Scott Marlowe
• Re: 4s query want to run faster
  • From: Adonias Malosso
• Re: 4s query want to run faster
  • From: Claus Guttesen
• Re: 4s query want to run faster
  • From: Adonias Malosso
• Re: 4s query want to run faster
  • From: Claus Guttesen
• Re: 4s query want to run faster
  • From: Adonias Malosso
• Re: 4s query want to run faster
  • From: Scott Marlowe
• 4s query want to run faster
  • From: Adonias Malosso
• Re: 7 hrs for a pg_restore?
  • From: Vivek Khera
• Re: 7 hrs for a pg_restore?
  • From: Tom Lane
• Re: 7 hrs for a pg_restore?
  • From: Guillaume Cottenceau
• Re: 7 hrs for a pg_restore?
  • From: Matthew
• Re: Question about shared_buffers and cpu usage
  • From: Dave Cramer
• Re: planner favors seq scan too early
  • From: Richard Huxton
• Re: Question about shared_buffers and cpu usage
  • From: Scott Marlowe
• planner favors seq scan too early
  • From: Markus Bertheau
• Re: 7 hrs for a pg_restore?
  • From: Chris
• Re: 7 hrs for a pg_restore?
  • From: Gregory Stark
• Question about shared_buffers and cpu usage
  • From: bh yuan
• Re: 7 hrs for a pg_restore?
  • From: Chris
• Re: 7 hrs for a pg_restore?
  • From: Gregory Stark
• Re: 7 hrs for a pg_restore?
  • From: Tom Lane
• Re: 7 hrs for a pg_restore?
  • From: Jeff Davis
• Re: 7 hrs for a pg_restore?
  • From: Matthew
• Re: 7 hrs for a pg_restore?
  • From: Jeff Davis
• Re: 7 hrs for a pg_restore?
  • From: Erik Jones
• Re: 7 hrs for a pg_restore?
  • From: Matthew
• Re: 7 hrs for a pg_restore?
  • From: Tom Lane
• Re: 7 hrs for a pg_restore?
  • From: Erik Jones
• Re: Anyone using a SAN?
  • From: Michael Stone
• Re: Anyone using a SAN?
  • From: Michael Stone
• Re: 7 hrs for a pg_restore?
  • From: Gregory Stark
• Re: Anyone using a SAN?
  • From: C.
• Re: Anyone using a SAN?
  • From: Matthew
• Re: 7 hrs for a pg_restore?
  • From: Douglas J Hunley
• Re: 7 hrs for a pg_restore?
  • From: Douglas J Hunley
• Re: Need Help selecting Large Data From PQSQL
  • From: Richard Huxton
• Re: 7 hrs for a pg_restore?
  • From: ohp
• Re: mis-estimate in nested query causes slow runtimes
  • From: Chris Kratz
• Need Help selecting Large Data From PQSQL
  • From: shilpa.raghavendra
• Re: 7 hrs for a pg_restore?
  • From: Pavan Deolasee
• Re: Anyone using a SAN?
  • From: Sven Geisler
• Re: Fwd: wal_sync_methods for AIX
  • From: Greg Smith
• Re: 7 hrs for a pg_restore?
  • From: Greg Smith
• Re: wal_sync_methods for AIX
  • From: Erik Jones
• Re: wal_sync_methods for AIX
  • From: Dan Langille
• Re: 7 hrs for a pg_restore?
  • From: Erik Jones
• Re: 7 hrs for a pg_restore?
  • From: Douglas J Hunley
• Re: 7 hrs for a pg_restore?
  • From: Douglas J Hunley
• Re: Fwd: wal_sync_methods for AIX
  • From: JP Fletcher
• Re: 7 hrs for a pg_restore?
  • From: Dave Cramer
• Re: 7 hrs for a pg_restore?
  • From: Jeff
• Re: 7 hrs for a pg_restore?
  • From: Jeff Davis
• Re: 7 hrs for a pg_restore?
  • From: Jeff Davis
• Re: 7 hrs for a pg_restore?
  • From: Douglas J Hunley
• Re: 7 hrs for a pg_restore?
  • From: Dave Cramer
• Re: 7 hrs for a pg_restore?
  • From: Douglas J Hunley
• Re: 7 hrs for a pg_restore?
  • From: Douglas J Hunley
• Re: 7 hrs for a pg_restore?
  • From: Douglas J Hunley
• Re: 7 hrs for a pg_restore?
  • From: Douglas J Hunley
• Re: 7 hrs for a pg_restore?
  • From: Jeff Davis
• Re: 7 hrs for a pg_restore?
  • From: Tom Lane
• Re: 7 hrs for a pg_restore?
  • From: Dave Cramer
• Re: 7 hrs for a pg_restore?
  • From: Richard Huxton
• Re: 7 hrs for a pg_restore?
  • From: Joshua D. Drake
• 7 hrs for a pg_restore?
  • From: Douglas J Hunley
• Re: Disable WAL completely
  • From: Andrew Sullivan
• strange plan choice
  • From: Cousin Marc
• Re: Disable WAL completely
  • From: Matthew
• Re: Anyone using a SAN?
  • From: Peter Koczan
• Re: shared_buffers in 8.3 w/ lots of RAM on dedicated PG machine
  • From: Greg Smith
• Re: mis-estimate in nested query causes slow runtimes
  • From: Chris Kratz
• Re: Disable WAL completely
  • From: Tobias Brox
• Re: Controling where temporary files are created
  • From: Albert Cervera Areny
• Re: Disable WAL completely
  • From: Erik Jones
• Controling where temporary files are created
  • From: Nikolas Everett
• Re: Disable WAL completely
  • From: hubert depesz lubaczewski
• Re: Disable WAL completely
  • From: Kathirvel, Jeevanandam
• Re: Disable WAL completely
  • From: A. Kretschmer
• Re: Disable WAL completely
  • From: hubert depesz lubaczewski
• Disable WAL completely
  • From: Kathirvel, Jeevanandam
• Re: shared_buffers in 8.3 w/ lots of RAM on dedicated PG machine
  • From: Peter Schuller
• Re: Example web access to Postgres DB
  • From: Adam Tauno Williams
• Re: Example web access to Postgres DB
  • From: Dave Cramer
• Re: Example web access to Postgres DB
  • From: Bill Moran
• Re: Example web access to Postgres DB
  • From: Tino Wildenhain
• Example web access to Postgres DB
  • From: Mohamed Ali JBELI
• Re: Anyone using a SAN?
  • From: Greg Smith
• Re: wal_sync_methods for AIX
  • From: Erik Jones
• Re: wal_sync_methods for AIX
  • From: Joshua D. Drake
• wal_sync_methods for AIX
  • From: Dan Langille
• Re: shared_buffers in 8.3 w/ lots of RAM on dedicated PG machine
  • From: Erik Jones
• Re: shared_buffers in 8.3 w/ lots of RAM on dedicated PG machine
  • From: Jignesh K. Shah
• Re: shared_buffers in 8.3 w/ lots of RAM on dedicated PG machine
  • From: Joshua D. Drake
• Re: shared_buffers in 8.3 w/ lots of RAM on dedicated PG machine
  • From: Erik Jones
• Re: shared_buffers in 8.3 w/ lots of RAM on dedicated PG machine
  • From: Josh Berkus
• Re: Query slows after offset of 100K
  • From: Matthew
• Re: shared_buffers in 8.3 w/ lots of RAM on dedicated PG machine
  • From: Greg Smith
• Re: Creating and updating table using function parameter reference
  • From: Linux Guru
• Re: shared_buffers in 8.3 w/ lots of RAM on dedicated PG machine
  • From: Peter Schuller
• Re: shared_buffers in 8.3 w/ lots of RAM on dedicated PG machine
  • From: Kenneth Marshall
• shared_buffers in 8.3 w/ lots of RAM on dedicated PG machine
  • From: Peter Schuller
• Re: Avoid long-running transactions in a long-runningstored procedure?
  • From: David Crane
• Re: Avoid long-running transactions in a long-running stored procedure?
  • From: Ow Mun Heng
• Re: Avoid long-running transactions in a long-running stored procedure?
  • From: Josh Berkus
• Avoid long-running transactions in a long-running stored procedure?
  • From: David Crane
• Re: Query slows after offset of 100K
  • From: Tom Lane
• Re: Query slows after offset of 100K
  • From: Greg Smith
• Re: Join Query Perfomance Issue
  • From: Chris
• Re: Query slows after offset of 100K
  • From: Tom Lane
• Re: Query slows after offset of 100K
  • From: Mark Lewis
• Re: Query slows after offset of 100K
  • From: Michael Lorenz
• Re: Query slows after offset of 100K
  • From: Tom Lane
• Query slows after offset of 100K
  • From: Michael Lorenz
• Re: Creating and updating table using function parameter reference
  • From: Albert Cervera Areny
• Re: Creating and updating table using function parameter reference
  • From: Linux Guru
• Re: Join Query Perfomance Issue
  • From: Thomas Zaksek
• Re: Anyone using a SAN?
  • From: Greg Stark
• Re: Anyone using a SAN?
  • From: Peter Koczan
• Re: Anyone using a SAN?
  • From: Bruce Momjian
• Re: Anyone using a SAN?
  • From: Scott Marlowe
• Re: Anyone using a SAN?
  • From: Tobias Brox
• Re: Anyone using a SAN?
  • From: Greg Smith
• Re: HOT TOAST?
  • From: Josh Berkus
• Re: Anyone using a SAN?
  • From: Arjen van der Meijden
• Re: Join Query Perfomance Issue
  • From: Scott Marlowe
• Re: Anyone using a SAN?
  • From: Tobias Brox
• Re: Optimizing No matching record Queries
  • From: Gregory Stark
• Re: Dell Perc/6
  • From: Tore Halset
• Re: Optimizing No matching record Queries
  • From: Pallav Kalva
• Re: Dell Perc/6
  • From: Tore Halset
• Re: HOT TOAST?
  • From: Tom Lane
• Re: Anyone using a SAN?
  • From: Alex Deucher
• HOT TOAST?
  • From: Josh Berkus
• Re: Join Query Perfomance Issue
  • From: Thomas Zaksek
• Re: Anyone using a SAN?
  • From: Kenneth Marshall
• Re: Small DB Server Advice
  • From: Greg Smith
• Anyone using a SAN?
  • From: Peter Koczan
• Re: Dell Perc/6
  • From: Merlin Moncure
• Re: Join Query Perfomance Issue
  • From: Tom Lane
• Re: Creating and updating table using function parameter reference
  • From: Albert Cervera Areny
• Re: Small DB Server Advice
  • From: Matthew
• Re: Small DB Server Advice
  • From: Magnus Hagander
• Creating and updating table using function parameter reference
  • From: Linux Guru
• Re: Small DB Server Advice
  • From: Matthew
• Small DB Server Advice
  • From: Rory Campbell-Lange
• Re: Join Query Perfomance Issue
  • From: Thomas Zaksek
• Re: Join Query Perfomance Issue
  • From: Thomas Zaksek
• Re: Dell Perc/6
  • From: Dave Cramer
• Re: Update with Subquery Performance
  • From: Linux Guru
• Re: Dell Perc/6
  • From: Tore Halset
• Re: Optimizing No matching record Queries
  • From: Richard Huxton
• Re: Optimizing No matching record Queries
  • From: Gregory Stark
• Re: Optimizing No matching record Queries
  • From: Dean Gibson (DB Administrator)
• Re: Optimizing No matching record Queries
  • From: Stephen Denne
• Optimizing No matching record Queries
  • From: Pallav Kalva
• Re: Join Query Perfomance Issue
  • From: Peter Koczan
• Re: Dell Perc/6
  • From: Greg Smith
• Re: Questions about enabling SSL
  • From: fabrix peñuelas
• Dell Perc/6
  • From: Craig James
• Re: Update with Subquery Performance
  • From: Tom Lane
• Re: mis-estimate in nested query causes slow runtimes
  • From: Chris Kratz
• Re: mis-estimate in nested query causes slow runtimes
  • From: Chris Kratz
• Re: Join Query Perfomance Issue
  • From: Thomas Zaksek
• Re: Update with Subquery Performance
  • From: Linux Guru
• Re: Update with Subquery Performance
  • From: Linux Guru
• Re: Question about CLUSTER
  • From: Michael Fuhr
• Re: Questions about enabling SSL
  • From: Michael Fuhr
• Re: Questions about enabling SSL
  • From: Michael Fuhr
• Questions about enabling SSL
  • From: fabrix peñuelas
• Re: mis-estimate in nested query causes slow runtimes
  • From: Tom Lane
• mis-estimate in nested query causes slow runtimes
  • From: Chris Kratz
• Re: Join Query Perfomance Issue
  • From: Scott Marlowe
• Re: Join Query Perfomance Issue
  • From: Scott Marlowe
• Re: Question about CLUSTER
  • From: Scott Marlowe
• Re: Update with Subquery Performance
  • From: Scott Marlowe
• Question about CLUSTER
  • From: salman
• Join Query Perfomance Issue
  • From: Thomas Zaksek
• Re: Update with Subquery Performance
  • From: Tom Lane
• Re: Optimizer : query rewrite and execution plan ?
  • From: Tom Lane
• Update with Subquery Performance
  • From: Linux Guru
• Re: Optimizer : query rewrite and execution plan ?
  • From: Simon Riggs
• Re: Parallel inserts
  • From: Bruce Momjian
• Parallel inserts
  • From: Ivan Voras
• Re: Benchmark Data requested
  • From: Mark Wong
• Re: Benchmark Data requested
  • From: Mark Wong
• Wrong number of rows estimation by the planner
  • From: Yonatan Ben-Nes
• Re: index usage on arrays
  • From: Tom Lane
• Re: index usage on arrays
  • From: Oleg Bartunov
• index usage on arrays
  • From: andrew klassen
• Re: Benchmark Data requested --- pgloader CE design ideas
  • From: Mark Lewis
• Re: Benchmark Data requested --- pgloader CE design ideas
  • From: Kenneth Marshall
• Re: Benchmark Data requested --- pgloader CE design ideas
  • From: Matthew
• Re: Benchmark Data requested --- pgloader CE design ideas
  • From: Greg Smith
• Index Scan Backward + check additional condition before heap access
  • From: Markus Bertheau
• Re: Benchmark Data requested --- pgloader CE design ideas
  • From: Dimitri Fontaine
• Re: Benchmark Data requested --- pgloader CE design ideas
  • From: Greg Smith
• Re: Benchmark Data requested --- pgloader CE design ideas
  • From: Dimitri Fontaine
• Re: Benchmark Data requested --- pgloader CE design ideas
  • From: Dimitri Fontaine
• Re: Benchmark Data requested --- pgloader CE design ideas
  • From: Luke Lonergan
• Re: Benchmark Data requested --- pgloader CE design ideas
  • From: Dimitri Fontaine
• Re: Benchmark Data requested
  • From: Dimitri Fontaine
• Re: Benchmark Data requested --- pgloader CE design ideas
  • From: Jignesh K. Shah
• Re: Benchmark Data requested --- pgloader CE design ideas
  • From: Luke Lonergan
• Re: Optimizer : query rewrite and execution plan ?
  • From: Tom Lane
• Re: Benchmark Data requested --- pgloader CE design ideas
  • From: Greg Smith
• Re: Benchmark Data requested
  • From: Greg Smith
• Re: Optimizer : query rewrite and execution plan ?
  • From: Roberts, Jon
• Re: Optimizer : query rewrite and execution plan ?
  • From: Erik Jones
• Re: Optimizer : query rewrite and execution plan ?
  • From: Roberts, Jon
• Re: Benchmark Data requested --- pgloader CE design ideas
  • From: Dimitri Fontaine
• Re: Optimizer : query rewrite and execution plan ?
  • From: Theo Kramer
• Re: Optimizer : query rewrite and execution plan ?
  • From: Simon Riggs
• Re: Benchmark Data requested --- pgloader CE design ideas
  • From: Simon Riggs
• Re: Benchmark Data requested --- pgloader CE design ideas
  • From: Dimitri Fontaine
• Re: Benchmark Data requested
  • From: Dimitri Fontaine
• Re: Optimizer : query rewrite and execution plan ?
  • From: Richard Huxton
• Re: Optimizer : query rewrite and execution plan ?
  • From: SURANTYN Jean François
• Re: Optimizer : query rewrite and execution plan ?
  • From: Richard Huxton
• Optimizer : query rewrite and execution plan ?
  • From: SURANTYN Jean François
• Re: Benchmark Data requested
  • From: NikhilS
• Re: Benchmark Data requested
  • From: Greg Smith
• Re: Benchmark Data requested
  • From: Simon Riggs
• Re: Benchmark Data requested
  • From: Heikki Linnakangas
• Re: Benchmark Data requested
  • From: Jignesh K. Shah
• Re: Benchmark Data requested
  • From: Jignesh K. Shah
• Re: Benchmark Data requested
  • From: Heikki Linnakangas
• Re: Benchmark Data requested
  • From: Simon Riggs
• Re: Benchmark Data requested
  • From: Jignesh K. Shah
• Re: Benchmark Data requested
  • From: Simon Riggs
• Re: Benchmark Data requested
  • From: Dimitri Fontaine
• Re: Benchmark Data requested
  • From: Dimitri Fontaine
• Re: Benchmark Data requested
  • From: Jignesh K. Shah
• Re: Benchmark Data requested
  • From: Matthew
• Re: Benchmark Data requested
  • From: Richard Huxton
• Re: Benchmark Data requested
  • From: Matthew
• Re: Benchmark Data requested
  • From: Richard Huxton
• Re: Benchmark Data requested
  • From: Richard Huxton
• Re: Benchmark Data requested
  • From: Matthew
• Re: Benchmark Data requested
  • From: Simon Riggs
• Re: Performance issue using Tsearch2
  • From: Viviane Lestic
• Re: Benchmark Data requested
  • From: Richard Huxton
• Re: Benchmark Data requested
  • From: Simon Riggs
• Re: Benchmark Data requested
  • From: Matthew
• Re: Benchmark Data requested
  • From: Matthew
• Re: Benchmark Data requested
  • From: Richard Huxton
• Re: Benchmark Data requested
  • From: Matthew
• Re: Benchmark Data requested
  • From: Simon Riggs
• Re: Benchmark Data requested
  • From: Dimitri Fontaine
• Re: Performance issue using Tsearch2
  • From: Guillaume Smet
• Re: Performance issue using Tsearch2
  • From: Ansgar -59cobalt- Wiechers
• Performance issue using Tsearch2
  • From: Viviane Lestic
• Re: Performance problems inside a stored procedure.
  • From: Matthew Lunnon
• Re: Benchmark Data requested
  • From: Simon Riggs
• Re: Benchmark Data requested
  • From: Simon Riggs
• Re: Benchmark Data requested
  • From: Jignesh K. Shah
• Re: Benchmark Data requested
  • From: Jignesh K. Shah
• Re: Benchmark Data requested
  • From: Gregory Stark
• Re: Benchmark Data requested
  • From: Gregory Stark
• Re: Benchmark Data requested
  • From: Greg Smith
• Re: Benchmark Data requested
  • From: Jignesh K. Shah
• Re: Benchmark Data requested
  • From: Greg Smith
• Re: Benchmark Data requested
  • From: Jignesh K. Shah
• Re: Benchmark Data requested
  • From: Luke Lonergan
• Re: Benchmark Data requested
  • From: Luke Lonergan
• Re: Benchmark Data requested
  • From: Simon Riggs
• Re: Benchmark Data requested
  • From: Greg Smith
• Re: Benchmark Data requested
  • From: Simon Riggs
• Re: Benchmark Data requested
  • From: Claus Guttesen
• Re: Benchmark Data requested
  • From: Luke Lonergan
• Benchmark Data requested
  • From: Simon Riggs
• Re: slow 8.2.6 with 50 connections
  • From: Greg Smith
• Re: slow 8.2.6 with 50 connections
  • From: Pavel Stehule
• Re: slow 8.2.6 with 50 connections
  • From: Scott Marlowe
• slow 8.2.6 with 50 connections
  • From: Pavel Stehule
• Re: Storage space usage
  • From: Decibel!
• Storage space usage
  • From: Gangadharan S.A.
• Re: How do I bulk insert to a table without affecting read performance on that table?
  • From: Kevin Grittner
• Re: JDBC/Stored procedure performance issue
  • From: Claire McLister
• Re: planner chooses unoptimal plan on joins with complex key
  • From: Dmitry Potapov
• Re: planner chooses unoptimal plan on joins with complex key
  • From: Tom Lane
• Re: 8x2.5" or 6x3.5" disks
  • From: Mike Smith
• Re: analyze
  • From: Scott Marlowe
• Re: analyze
  • From: Andrew Sullivan
• Re: JDBC/Stored procedure performance issue
  • From: Tom Lane
• Re: Performance problems inside a stored procedure.
  • From: Matthew Lunnon
• Re: RAID arrays and performance
  • From: Kevin Grittner
• Re: RAID arrays and performance
  • From: Gregory Stark
• Re: RAID arrays and performance
  • From: Kevin Grittner
• Re: RAID arrays and performance
  • From: Gregory Stark
• Re: planner chooses unoptimal plan on joins with complex key
  • From: Dmitry Potapov
• Re: RAID arrays and performance
  • From: Matthew
• Re: 8x2.5" or 6x3.5" disks
  • From: Craig James
• Re: 8x2.5" or 6x3.5" disks
  • From: Scott Marlowe
• Re: RAID arrays and performance
  • From: Gregory Stark
• analyze
  • From: Adrian Moisey
• Re: Performance problems inside a stored procedure.
  • From: Euler Taveira de Oliveira
• Re: 8x2.5" or 6x3.5" disks
  • From: Mike Smith
• Re: 8x2.5" or 6x3.5" disks
  • From: Arjen van der Meijden
• Re: JDBC/Stored procedure performance issue
  • From: Matthew Lunnon
• Re: 8x2.5" or 6x3.5" disks
  • From: Claus Guttesen
• Re: 8x2.5" or 6x3.5" disks
  • From: david
• Re: Hard Drive Usage for Speeding up Big Queries
  • From: Merlin Moncure
• Re: JDBC/Stored procedure performance issue
  • From: Tom Lane
• Re: 8x2.5" or 6x3.5" disks
  • From: Arjen van der Meijden
• Re: Vacuum and FSM page size
  • From: Decibel!
• 8x2.5" or 6x3.5" disks
  • From: Christian Nicolaisen
• JDBC/Stored procedure performance issue
  • From: Claire McLister
• Re: Performance issues migrating from 743 to 826
  • From: Matthew Lunnon
• Re: Performance issues migrating from 743 to 826
  • From: Matthew Lunnon
• Re: Performance issues migrating from 743 to 826
  • From: Scott Marlowe
• Re: Performance issues migrating from 743 to 826
  • From: Matthew Lunnon
• Re: Hard Drive Usage for Speeding up Big Queries
  • From: Scott Marlowe
• Re: Performance issues migrating from 743 to 826
  • From: Scott Marlowe
• Re: Linux/PostgreSQL scalability issue - problem with 8 cores
  • From: Matthew
• Hard Drive Usage for Speeding up Big Queries
  • From: Alex Hochberger
• Re: Performance issues migrating from 743 to 826
  • From: Gregory Stark
• Re: Slow set-returning functions
  • From: Dean Rasheed
• Re: Performance problems inside a stored procedure.
  • From: Matthew Lunnon
• Re: Performance problems inside a stored procedure.
  • From: Heikki Linnakangas
• Performance problems inside a stored procedure.
  • From: Matthew Lunnon
• Performance issues migrating from 743 to 826
  • From: Matthew Lunnon
• Re: 8.3rc1 Out of memory when performing update
  • From: Guillaume Smet
• Re: Postgres 8.2 memory weirdness
  • From: Tory M Blue
• Re: 8.3rc1 Out of memory when performing update
  • From: Stephen Denne
• Re: 1 or 2 servers for large DB scenario.
  • From: Merlin Moncure
• Re: 8.3rc1 Out of memory when performing update
  • From: Tom Lane
• Re: 1 or 2 servers for large DB scenario.
  • From: Jignesh K. Shah
• Re: Postgres 8.2 memory weirdness
  • From: Greg Smith
• Re: Vacuum and FSM page size
  • From: Scott Marlowe
• Re: Vacuum and FSM page size
  • From: Thomas Lozza
• Re: Slow set-returning functions
  • From: Merlin Moncure
• Re: 8.3rc1 Out of memory when performing update
  • From: Stephen Denne
• Re: Slow set-returning functions
  • From: Marcin Stępnicki
• Re: Slow set-returning functions
  • From: Dean Rasheed
• Re: 1 or 2 servers for large DB scenario.
  • From: Heikki Linnakangas
• Re: How do I bulk insert to a table without affecting read performance on that table?
  • From: Scott Marlowe
• Re: How do I bulk insert to a table without affecting read performance on that table?
  • From: growse
• Re: How do I bulk insert to a table without affecting read performance on that table?
  • From: Scott Marlowe
• How do I bulk insert to a table without affecting read performance on that table?
  • From: growse
• Re: Linux/PostgreSQL scalability issue - problem with 8 cores
  • From: Simon Riggs
• Re: 8.3rc1 Out of memory when performing update
  • From: Magnus Hagander
• Re: 8.3rc1 Out of memory when performing update
  • From: Roberts, Jon
• Re: 8.3rc1 Out of memory when performing update
  • From: cgallant
• Re: Postgres 8.2 memory weirdness
  • From: Tory M Blue
• Re: 1 or 2 servers for large DB scenario.
  • From: Matthew
• Re: 1 or 2 servers for large DB scenario.
  • From: Matthew
• Re: 1 or 2 servers for large DB scenario.
  • From: Greg Smith
• 1 or 2 servers for large DB scenario.
  • From: David Brain
• Re: 8.3rc1 Out of memory when performing update
  • From: Stephen Denne
• Re: Making the most of memory?
  • From: Florian Weimer
• Re: 8.3rc1 Out of memory when performing update
  • From: Tom Lane
• Re: 8.3rc1 Out of memory when performing update
  • From: Stephen Denne
• Re: 8.3rc1 Out of memory when performing update
  • From: Tom Lane
• Re: planner chooses unoptimal plan on joins with complex key
  • From: Tom Lane
• Re: Configuration settings (shared_buffers, etc) in Linux: puzzled
  • From: Fernando Ike
• Re: 8.3rc1 Out of memory when performing update
  • From: Fernando Ike
• 8.3rc1 Out of memory when performing update
  • From: Stephen Denne
• Re: Configuration settings (shared_buffers, etc) in Linux: puzzled
  • From: Greg Smith
• Re: Postgres 8.2 memory weirdness
  • From: Greg Smith
• Configuration settings (shared_buffers, etc) in Linux: puzzled
  • From: Rick Schumeyer
• Re: Making the most of memory?
  • From: Merlin Moncure
• Re: Making the most of memory?
  • From: Merlin Moncure
• Re: Postgres 8.2 memory weirdness
  • From: Tory M Blue
• Re: Making the most of memory?
  • From: Chris Browne
• Re: Making the most of memory?
  • From: Chris Browne
• Re: Vacuum and FSM page size
  • From: Scott Marlowe
• Re: Making the most of memory?
  • From: Florian Weimer
• Re: Making the most of memory?
  • From: Matthew
• Re: Making the most of memory?
  • From: Merlin Moncure
• Re: Making the most of memory?
  • From: Heikki Linnakangas
• Re: Making the most of memory?
  • From: Steinar H. Gunderson
• Re: Making the most of memory?
  • From: Scott Marlowe
• Re: Postgres 8.2 memory weirdness
  • From: Greg Smith
• Re: Making the most of memory?
  • From: Greg Smith
• Re: Making the most of memory?
  • From: Brian Hurt
• Re: Making the most of memory?
  • From: Craig James
• Re: Vacuum and FSM page size
  • From: Tom Lane
• Re: Making the most of memory?
  • From: A.M.
• Re: Making the most of memory?
  • From: Guy Rouillier
• Re: Vacuum and FSM page size
  • From: Vivek Khera
• Re: Making the most of memory?
  • From: Rich
• Re: Making the most of memory?
  • From: Scott Marlowe
• Vacuum and FSM page size
  • From: Thomas Lozza
• Postgres 8.2 memory weirdness
  • From: Tory M Blue
• Re: planner chooses unoptimal plan on joins with complex key
  • From: Tom Lane
• Re: Making the most of memory?
  • From: Bill Moran
• Re: planner chooses unoptimal plan on joins with complex key
  • From: Guillaume Smet
• planner chooses unoptimal plan on joins with complex key
  • From: Dmitry Potapov
• *_cost recommendation with 8.3 and a fully cached db
  • From: Guillaume Smet
• Re: Workaround for cross column stats dependency
  • From: Guillaume Smet
• Re: SELECT * FROM table is too slow
  • From: Guillaume Cottenceau
• Re: Making the most of memory?
  • From: Scott Marlowe
• Making the most of memory?
  • From: Joshua Fielek
• Re: Workaround for cross column stats dependency
  • From: Guillaume Smet
• Re: Workaround for cross column stats dependency
  • From: Tom Lane
• Workaround for cross column stats dependency
  • From: Guillaume Smet
• Re: Optimizing queries that use temporary tables
  • From: Scott Marlowe
• Re: SELECT * FROM table is too slow
  • From: Joshua D. Drake
• Re: SELECT * FROM table is too slow
  • From: Luiz K. Matsumura
• Optimizing queries that use temporary tables
  • From: Luiz K. Matsumura
• Re: 8.3 synchronous_commit
  • From: Hannes Dorbath
• Re: 8.3 synchronous_commit
  • From: Hannes Dorbath
• Re: 8.3 synchronous_commit
  • From: Florian Weimer
• Re: 8.3 synchronous_commit
  • From: Guillaume Smet
• Re: scheduler
  • From: Luke Lonergan
• Re: scheduler
  • From: david
• Re: 8.3 synchronous_commit
  • From: Florian Weimer
• Re: scheduler
  • From: Adrian Moisey
• Re: scheduler
  • From: Claus Guttesen
• scheduler
  • From: Adrian Moisey
• Re: 8.3 synchronous_commit
  • From: Fernando Ike
• Re: 8.3 synchronous_commit
  • From: Greg Smith
• Re: 8.3 synchronous_commit
  • From: Jeff Davis
• Re: 8.3 synchronous_commit
  • From: Greg Smith
• Re: 8.3 synchronous_commit
  • From: Jeff Davis
• Re: 8.3 synchronous_commit
  • From: Pavel Stehule
• 8.3 synchronous_commit
  • From: Hannes Dorbath
• Re: strange pauses
  • From: Decibel!
• Re: Slow performance with left outer join
  • From: Pavel Stehule
• Re: Slow performance with left outer join
  • From: Tom Lane
• Re: Slow performance with left outer join
  • From: Pavel Stehule
• Slow performance with left outer join
  • From: Marten Verhoeven
• Re: strange pauses
  • From: Adrian Moisey
• Re: Slow set-returning functions
  • From: Tom Lane
• Re: Slow set-returning functions
  • From: Dean Rasheed
• Re: Slow set-returning functions
  • From: Merlin Moncure
• Re: Slow set-returning functions
  • From: Heikki Linnakangas
• Slow set-returning functions
  • From: Dean Rasheed
• Re: [OT] RAID controllers blocking one another?
  • From: david
• Re: Tuning Postgresql on Windows XP Pro 32 bit [was on HACKERS list]
  • From: Kevin Grittner
• Re: [OT] RAID controllers blocking one another?
  • From: Sean Davis
• Re: [OT] RAID controllers blocking one another?
  • From: Greg Smith
• Re: strange pauses
  • From: Scott Marlowe
• Re: [OT] RAID controllers blocking one another?
  • From: Sean Davis
• Re: strange pauses
  • From: Alvaro Herrera
• Re: strange pauses
  • From: Adrian Moisey
• Re: strange pauses
  • From: Adrian Moisey
• Re: [OT] RAID controllers blocking one another?
  • From: Steinar H. Gunderson
• Re: [OT] RAID controllers blocking one another?
  • From: Greg Smith
• Re: [OT] RAID controllers blocking one another?
  • From: Scott Marlowe
• [OT] RAID controllers blocking one another?
  • From: Sean Davis
• Re: strange pauses
  • From: Scott Marlowe
• Re: strange pauses
  • From: Brian Herlihy
• Re: strange pauses
  • From: Adrian Moisey
• Re: strange pauses
  • From: Greg Smith
• Re: strange pauses
  • From: Scott Marlowe
• Re: strange pauses
  • From: Tom Lane
• Re: strange pauses
  • From: Richard Huxton
• strange pauses
  • From: Adrian Moisey
• Re: Linux/PostgreSQL scalability issue - problem with 8 cores
  • From: Tom Lane
• Re: Linux/PostgreSQL scalability issue - problem with 8 cores
  • From: Jakub Ouhrabka
• Tuning Postgresql on Windows XP Pro 32 bit [was on HACKERS list]
  • From: Doug Knight
• Re: Linux/PostgreSQL scalability issue - problem with 8 cores
  • From: Tom Lane
• Re: Linux/PostgreSQL scalability issue - problem with 8 cores
  • From: Tom Lane
• Re: Linux/PostgreSQL scalability issue - problem with 8 cores
  • From: Jakub Ouhrabka
• Re: Linux/PostgreSQL scalability issue - problem with 8 cores
  • From: Adrian Moisey
• Re: Linux/PostgreSQL scalability issue - problem with 8 cores
  • From: Jakub Ouhrabka
• Re: Saving result set of SELECT to table column
  • From: Robins Tharakan
• Re: Seq scans on indexed columns.
  • From: Shane Ambler
• Re: Saving result set of SELECT to table column
  • From: Ansgar -59cobalt- Wiechers
• Saving result set of SELECT to table column
  • From: Patric
• Re: Linux/PostgreSQL scalability issue - problem with 8 cores
  • From: Tom Lane
• Re: Seq scans on indexed columns.
  • From: Guillaume Cottenceau
• Seq scans on indexed columns.
  • From: Yannick Le Guédart
• Re: Best way to index IP data?
  • From: Michael Stone
• Re: Best way to index IP data?
  • From: Florian Weimer
• Re: Linux/PostgreSQL scalability issue - problem with 8 cores
  • From: Jakub Ouhrabka
• Re: Best way to index IP data?
  • From: Michael Stone
• Re: Best way to index IP data?
  • From: Florian Weimer
• Re: Inheritance, unique keys and performance
  • From: Tom Lane
• Re: Inheritance, unique keys and performance
  • From: Julian Scarfe
• Re: Inheritance, unique keys and performance
  • From: Tom Lane
• Re: Inheritance, unique keys and performance
  • From: Julian Scarfe
• Re: Inheritance, unique keys and performance
  • From: Tom Lane
• Inheritance, unique keys and performance
  • From: Julian Scarfe
• Re: Best way to index IP data?
  • From: D'Arcy J.M. Cain
• Re: Simple select, but takes long time
  • From: Tom Lane
• Re: Simple select, but takes long time
  • From: andrew
• Re: Best way to index IP data?
  • From: david
• Re: Best way to index IP data?
  • From: Greg Smith
• Re: Simple select, but takes long time
  • From: Tom Lane
• Re: Best way to index IP data?
  • From: Michael Stone
• Simple select, but takes long time
  • From: James DeMichele
• Re: Best way to index IP data?
  • From: Michael Stone
• Re: Best way to index IP data?
  • From: Michael Stone
• Re: Best way to index IP data?
  • From: Joshua D. Drake
• Re: Best way to index IP data?
  • From: Tom Lane
• Re: Best way to index IP data?
  • From: Joshua D. Drake
• Re: Best way to index IP data?
  • From: Michael Stone
• Re: Best way to index IP data?
  • From: Michael Stone
• Re: Best way to index IP data?
  • From: Tom Lane
• Re: Best way to index IP data?
  • From: Michael Stone
• Re: Best way to index IP data?
  • From: Steve Atkins
• Re: Best way to index IP data?
  • From: Joshua D. Drake
• Re: Best way to index IP data?
  • From: Steve Atkins
• Re: Best way to index IP data?
  • From: Andrew Sullivan
• Re: Best way to index IP data?
  • From: Pomarede Nicolas
• Re: Best way to index IP data?
  • From: Steve Atkins
• Re: Best way to index IP data?
  • From: Andrew Sullivan
• Re: Best way to index IP data?
  • From: Michael Stone
• Re: Best way to index IP data?
  • From: Michael Stone
• Re: Best way to index IP data?
  • From: Alvaro Herrera
• Re: Best way to index IP data?
  • From: Michael Stone
• Re: Best way to index IP data?
  • From: Michael Stone
• Re: Best way to index IP data?
  • From: D'Arcy J.M. Cain
• Re: Best way to index IP data?
  • From: Tom Lane
• Re: Evaluating boolean formula: slow performance
  • From: Jörg Kiegeland
• Evaluating boolean formula: slow performance
  • From: Jörg Kiegeland
• Re: Best way to index IP data?
  • From: Michael Stone
• Re: Best way to index IP data?
  • From: Joshua D. Drake
• Re: Best way to index IP data?
  • From: Steve Atkins
• Re: Best way to index IP data?
  • From: Pomarede Nicolas
• Re: Best way to index IP data?
  • From: Andrew Sullivan
• Re: Best way to index IP data?
  • From: Tom Lane
• Re: Linux/PostgreSQL scalability issue - problem with 8 cores
  • From: Tom Lane
• Re: Linux/PostgreSQL scalability issue - problem with 8 cores
  • From: Jakub Ouhrabka
• Re: Best way to index IP data?
  • From: Pomarede Nicolas
• Re: not exists clause
  • From: Guy Rouillier
• Re: Best way to index IP data?
  • From: Jonah H. Harris
• Re: Best way to index IP data?
  • From: Steve Atkins
• Re: Best way to index IP data?
  • From: Joshua D. Drake
• Best way to index IP data?
  • From: Kevin Kempter
• Re: not exists clause
  • From: Josh Berkus
• not exists clause
  • From: S Golly
• Re: big database performance
  • From: Jared Mauch
• Re: big database performance
  • From: Jared Mauch
• Re: Search for fixed set of keywords
  • From: Oleg Bartunov
• Re: big database performance
  • From: Stephane Bailliez
• Re: Search for fixed set of keywords
  • From: Jörg Kiegeland
• Re: big database performance
  • From: Adrian Moisey
• Re: big database performance
  • From: Adrian Moisey
• Re: big database performance
  • From: Simon Riggs
• Re: big database performance
  • From: Greg Smith
• Re: After Vacuum Analyse - Procedure performance notimproved - Innner select is faster
  • From: Erik Jones
• Re: big database performance
  • From: Jared Mauch
• Re: big database performance
  • From: Guillaume Smet
• Re: big database performance
  • From: Joshua D. Drake
• Re: big database performance
  • From: Alan Hodgson
• Re: big database performance
  • From: Adrian Moisey
• Re: Search for fixed set of keywords
  • From: Oleg Bartunov
• Search for fixed set of keywords
  • From: Jörg Kiegeland
• Re: big database performance
  • From: Frank Habermann
• Re: big database performance
  • From: Joshua D. Drake
• big database performance
  • From: Adrian Moisey
• Re: After Vacuum Analyse - Procedure performance notimproved - Innner select is faster
  • From: Anoo Sivadasan Pillai
• Re: After Vacuum Analyse - Procedure performance not improved - Innner select is faster
  • From: Alvaro Herrera
• After Vacuum Analyse - Procedure performance not improved - Innner select is faster
  • From: Anoo Sivadasan Pillai
• Re: Performance of aggregates over set-returning functions
  • From: Tom Lane
• Re: Performance of aggregates over set-returning functions
  • From: John Smith
• Re: Performance of aggregates over set-returning functions
  • From: Tom Lane
• Performance of aggregates over set-returning functions
  • From: John Smith
• Re: Loss of cache when persistent connexion is closed
  • From: Tom Lane
• Loss of cache when persistent connexion is closed
  • From: Guillaume Pungeot
• Re: Linux/PostgreSQL scalability issue - problem with 8 cores
  • From: Tom Lane
• Re: Linux/PostgreSQL scalability issue - problem with 8 cores
  • From: Jakub Ouhrabka
• Re: Linux/PostgreSQL scalability issue - problem with 8 cores
  • From: Tom Lane
• Re: Linux/PostgreSQL scalability issue - problem with 8 cores
  • From: Tom Lane
• Re: concurrent inserts into two separate tables are very slow
  • From: Scott Marlowe
• Re: concurrent inserts into two separate tables are very slow
  • From: Sergei Shelukhin
• Re: Linux/PostgreSQL scalability issue - problem with 8 cores
  • From: Tom Lane
• Re: concurrent inserts into two separate tables are very slow
  • From: Scott Marlowe
• concurrent inserts into two separate tables are very slow
  • From: Sergei Shelukhin
• Re: Linux/PostgreSQL scalability issue - problem with 8 cores
  • From: Alvaro Herrera
• Re: Linux/PostgreSQL scalability issue - problem with 8 cores
  • From: Jakub Ouhrabka
• Re: Linux/PostgreSQL scalability issue - problem with 8 cores
  • From: David Boreham
• Re: Linux/PostgreSQL scalability issue - problem with 8 cores
  • From: James Mansion
• Re: Commit takes a long time.
  • From: Simon Riggs
• Re: Commit takes a long time.
  • From: Peter Childs
• Re: Linux/PostgreSQL scalability issue - problem with 8 cores
  • From: Jakub Ouhrabka
• Re: Linux/PostgreSQL scalability issue - problem with 8 cores
  • From: Alvaro Herrera
• Re: Linux/PostgreSQL scalability issue - problem with 8 cores
  • From: Jakub Ouhrabka
• Re: Linux/PostgreSQL scalability issue - problem with 8 cores
  • From: Jakub Ouhrabka
• Re: Linux/PostgreSQL scalability issue - problem with 8 cores
  • From: Tom Lane
• Re: Commit takes a long time.
  • From: Tom Lane
• Re: Linux/PostgreSQL scalability issue - problem with 8 cores
  • From: Sven Geisler
• Re: Commit takes a long time.
  • From: Pavel Stehule
• Commit takes a long time.
  • From: Peter Childs
• Linux/PostgreSQL scalability issue - problem with 8 cores
  • From: Jakub Ouhrabka
• Re: [GENERAL] Can't make backup
  • From: Sebastián Baioni
• Re: More shared buffers causes lower performances
  • From: Merlin Moncure
• Re: More shared buffers causes lower performances
  • From: Guillaume Smet
• Re: Evaluation of PG performance vs MSDE/MSSQL 2000 (not 2005)
  • From: Kevin Grittner
• Re: Anyone running on RHEL Cluster?
  • From: Mikko Partio
• Re: More shared buffers causes lower performances
  • From: Tom Lane
• Re: More shared buffers causes lower performances
  • From: Alvaro Herrera
• Re: With 4 disks should I go for RAID 5 or RAID 10
  • From: Bill Moran
• Re: More shared buffers causes lower performances
  • From: Gregory Stark
• Re: With 4 disks should I go for RAID 5 or RAID 10
  • From: Jean-David Beyer
• Re: With 4 disks should I go for RAID 5 or RAID 10
  • From: Vivek Khera
• Re: With 4 disks should I go for RAID 5 or RAID 10
  • From: Vivek Khera
• Re: More shared buffers causes lower performances
  • From: Tom Lane
• Re: More shared buffers causes lower performances
  • From: Greg Smith
• Re: With 4 disks should I go for RAID 5 or RAID 10
  • From: Mark Mielke
• Re: pg_dump performance
  • From: Jared Mauch
• Re: More shared buffers causes lower performances
  • From: Gregory Stark
• Re: With 4 disks should I go for RAID 5 or RAID 10
  • From: Bill Moran
• Re: More shared buffers causes lower performances
  • From: Alvaro Herrera
• Re: pg_dump performance
  • From: Gregory Stark
• Re: More shared buffers causes lower performances
  • From: Magnus Hagander
• Re: More shared buffers causes lower performances
  • From: Guillaume Smet
• Re: With 4 disks should I go for RAID 5 or RAID 10
  • From: Shane Ambler
• Re: With 4 disks should I go for RAID 5 or RAID 10
  • From: Shane Ambler