Postgres Performance Date Index

• Thread Index

• 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
• Re: More shared buffers causes lower performances
  • From: Tom Lane
• Re: With 4 disks should I go for RAID 5 or RAID 10
  • From: Mark Mielke
• Re: With 4 disks should I go for RAID 5 or RAID 10
  • From: Greg Smith
• Re: With 4 disks should I go for RAID 5 or RAID 10
  • From: Shane Ambler
• Re: More shared buffers causes lower performances
  • From: Devrim GÜNDÜZ
• Re: More shared buffers causes lower performances
  • From: Greg Smith
• Re: More shared buffers causes lower performances
  • From: Guillaume Smet
• Re: With 4 disks should I go for RAID 5 or RAID 10
  • From: Greg Smith
• Re: With 4 disks should I go for RAID 5 or RAID 10
  • From: Mark Mielke
• Re: With 4 disks should I go for RAID 5 or RAID 10
  • From: david
• Re: With 4 disks should I go for RAID 5 or RAID 10
  • From: david
• Re: With 4 disks should I go for RAID 5 or RAID 10
  • From: Mark Mielke
• Re: With 4 disks should I go for RAID 5 or RAID 10
  • From: david
• Re: With 4 disks should I go for RAID 5 or RAID 10
  • From: Bill Moran
• Re: With 4 disks should I go for RAID 5 or RAID 10
  • From: Bill Moran
• Re: With 4 disks should I go for RAID 5 or RAID 10
  • From: Mark Mielke
• Re: With 4 disks should I go for RAID 5 or RAID 10
  • From: Mark Mielke
• Re: With 4 disks should I go for RAID 5 or RAID 10
  • From: Mark Mielke
• Re: With 4 disks should I go for RAID 5 or RAID 10
  • From: Mark Mielke
• Re: With 4 disks should I go for RAID 5 or RAID 10
  • From: david
• Re: More shared buffers causes lower performances
  • From: Guillaume Smet
• Re: pg_dump performance
  • From: Jared Mauch
• Re: With 4 disks should I go for RAID 5 or RAID 10
  • From: Mark Mielke
• Re: With 4 disks should I go for RAID 5 or RAID 10
  • From: david
• Re: With 4 disks should I go for RAID 5 or RAID 10
  • From: david
• Re: pg_dump performance
  • From: Heikki Linnakangas
• Re: With 4 disks should I go for RAID 5 or RAID 10
  • From: Bill Moran
• Re: pg_dump performance
  • From: Jared Mauch
• Re: With 4 disks should I go for RAID 5 or RAID 10
  • From: Florian Weimer
• Re: pg_dump performance
  • From: Heikki Linnakangas
• Re: With 4 disks should I go for RAID 5 or RAID 10
  • From: Fernando Hevia
• pg_dump performance
  • From: Jared Mauch
• Re: With 4 disks should I go for RAID 5 or RAID 10
  • From: david
• Re: With 4 disks should I go for RAID 5 or RAID 10
  • From: Fernando Hevia
• Re: With 4 disks should I go for RAID 5 or RAID 10
  • From: Fernando Hevia
• Re: More shared buffers causes lower performances
  • From: Greg Smith
• Re: With 4 disks should I go for RAID 5 or RAID 10
  • From: Greg Smith
• Anyone running on RHEL Cluster?
  • From: Chris Hoover
• Re: More shared buffers causes lower performances
  • From: Guillaume Smet
• Re: More shared buffers causes lower performances
  • From: Pavel Stehule
• Re: With 4 disks should I go for RAID 5 or RAID 10
  • From: Mark Mielke
• Re: More shared buffers causes lower performances
  • From: Guillaume Smet
• Re: With 4 disks should I go for RAID 5 or RAID 10
  • From: Bill Moran
• With 4 disks should I go for RAID 5 or RAID 10
  • From: Fernando Hevia
• Re: More shared buffers causes lower performances
  • From: Guillaume Smet
• Re: More shared buffers causes lower performances
  • From: Guillaume Smet
• Re: More shared buffers causes lower performances
  • From: Simon Riggs
• Re: More shared buffers causes lower performances
  • From: Cédric Villemain
• More shared buffers causes lower performances
  • From: Guillaume Smet
• Re: viewing source code
  • From: Michael Stone
• Re: viewing source code
  • From: Tom Lane
• Re: viewing source code
  • From: Trevor Talbot
• Re: viewing source code
  • From: Trevor Talbot
• Re: function body actors (was: viewing source code)
  • From: Andrew Sullivan
• Re: [HACKERS] function body actors (was: viewing source code)
  • From: Andrew Sullivan
• Re: viewing source code
  • From: Dan Langille
• Re: viewing source code
  • From: Merlin Moncure
• Re: function body actors (was: viewing source code)
  • From: Pavel Stehule
• Re: viewing source code
  • From: Bruce Momjian
• Re: function body actors (was: viewing source code)
  • From: Merlin Moncure
• Re: function body actors (was: viewing source code)
  • From: Pavel Stehule
• Re: function body actors (was: viewing source code)
  • From: Merlin Moncure
• Re: function body actors (was: viewing source code)
  • From: Tom Lane
• function body actors (was: viewing source code)
  • From: Merlin Moncure
• Re: viewing source code
  • From: Harald Armin Massa
• Re: viewing source code
  • From: Tom Lane
• Re: viewing source code
  • From: Merlin Moncure
• Re: viewing source code
  • From: Greg Smith
• Re: viewing source code
  • From: Andrew Sullivan
• Re: viewing source code
  • From: Alvaro Herrera
• Re: performance index scan vs bitmap-seq scan.
  • From: Scott Marlowe
• performance index scan vs bitmap-seq scan.
  • From: S Golly
• Re: viewing source code
  • From: Merlin Moncure
• Re: viewing source code
  • From: Andrew Sullivan
• Re: viewing source code
  • From: Roberts, Jon
• Re: viewing source code
  • From: Chris Browne
• Re: viewing source code
  • From: Andrew Sullivan
• Re: viewing source code
  • From: Andrew Sullivan
• Re: viewing source code
  • From: Merlin Moncure
• Re: viewing source code
  • From: Joshua D. Drake
• Re: viewing source code
  • From: Alvaro Herrera
• Re: viewing source code
  • From: Roberts, Jon
• Re: viewing source code
  • From: Joshua D. Drake
• Re: viewing source code
  • From: Roberts, Jon
• Re: viewing source code
  • From: Joshua D. Drake
• Re: viewing source code
  • From: Trevor Talbot
• Re: viewing source code
  • From: Alvaro Herrera
• Re: viewing source code
  • From: Merlin Moncure
• Re: viewing source code
  • From: Merlin Moncure
• Re: viewing source code
  • From: A.M.
• Re: viewing source code
  • From: Joshua D. Drake
• Re: viewing source code
  • From: Roberts, Jon
• Re: Reinitialising stats once only without restarting
  • From: Anton Melser
• Re: viewing source code
  • From: Merlin Moncure
• Re: viewing source code
  • From: Roberts, Jon
• Re: Dual core Opterons beating quad core Xeons?
  • From: Jan de Visser
• Re: Reinitialising stats once only without restarting
  • From: Alvaro Herrera
• Re: Minimizing dead tuples caused by update triggers
  • From: Dimitri Fontaine
• Reinitialising stats once only without restarting
  • From: Anton Melser
• Re: Dual core Opterons beating quad core Xeons?
  • From: Tom Lane
• Re: Dual core Opterons beating quad core Xeons?
  • From: Joshua D. Drake
• Re: Minimizing dead tuples caused by update triggers
  • From: Decibel!
• Re: Dual core Opterons beating quad core Xeons?
  • From: Decibel!
• Re: Measuring table and index bloat
  • From: Decibel!
• Re: Minimizing dead tuples caused by update triggers
  • From: Tom Lane
• Minimizing dead tuples caused by update triggers
  • From: Dan Harris
• Re: Dual core Opterons beating quad core Xeons?
  • From: Gregory Stark
• Re: Optimising a query
  • From: Paul Lambert
• Re: Dual core Opterons beating quad core Xeons?
  • From: Greg Smith
• Re: Dual core Opterons beating quad core Xeons?
  • From: Joshua D. Drake
• Re: Dual core Opterons beating quad core Xeons?
  • From: Ron Mayer
• Re: Dual core Opterons beating quad core Xeons?
  • From: Scott Marlowe
• Re: Dual core Opterons beating quad core Xeons?
  • From: Joshua D. Drake
• Re: Dual core Opterons beating quad core Xeons?
  • From: Scott Marlowe
• Re: Dual core Opterons beating quad core Xeons?
  • From: Joshua D. Drake
• Re: Dual core Opterons beating quad core Xeons?
  • From: Greg Smith
• Re: Optimising a query
  • From: Jeremy Harris
• Re: viewing source code
  • From: Alvaro Herrera
• Re: viewing source code
  • From: Roberts, Jon
• Re: viewing source code
  • From: Trevor Talbot
• Re: Dual core Opterons beating quad core Xeons?
  • From: Scott Marlowe
• Re: Dual core Opterons beating quad core Xeons?
  • From: Gregory Stark
• Re: Dual core Opterons beating quad core Xeons?
  • From: Cédric Villemain
• Dual core Opterons beating quad core Xeons?
  • From: Stuart Bishop
• Re: Optimising a query
  • From: Gregory Stark
• Re: Optimising a query
  • From: Gregory Stark
• Re: Optimising a query
  • From: Richard Huxton
• Re: Optimising a query
  • From: Paul Lambert
• Optimising a query
  • From: Paul Lambert
• Re: viewing source code
  • From: Alvaro Herrera
• Re: viewing source code
  • From: Joshua D. Drake
• Re: viewing source code
  • From: Richard Huxton
• Re: viewing source code
  • From: Roberts, Jon
• Re: viewing source code
  • From: Alvaro Herrera
• Re: viewing source code
  • From: Roberts, Jon
• Re: Evaluation of PG performance vs MSDE/MSSQL 2000 (not 2005)
  • From: Heikki Linnakangas
• Re: Evaluation of PG performance vs MSDE/MSSQL 2000 (not 2005)
  • From: Dave Page
• Re: viewing source code
  • From: Kris Jurka
• Re: Evaluation of PG performance vs MSDE/MSSQL 2000 (not 2005)
  • From: Robert Bernabe
• Re: Multi-threading friendliness
  • From: James Mansion
• Multi-threading friendliness (was: libgcc double-free, backend won't die)
  • From: Craig James
• Re: update 600000 rows
  • From: H. Hall
• Re: viewing source code
  • From: Joshua D. Drake
• Re: VACUUM FREEZE output more than double input
  • From: Kevin Grittner
• Re: viewing source code
  • From: Merlin Moncure
• Re: viewing source code
  • From: Roberts, Jon
• Re: libgcc double-free, backend won't die
  • From: Bruce Momjian
• Re: SELECT * FROM table is too slow
  • From: andrew
• Re: libgcc double-free, backend won't die
  • From: James Mansion
• Re: update 600000 rows
  • From: andrew
• Re: Large Objects and Toast
  • From: Usama Dar
• Re: libgcc double-free, backend won't die
  • From: Gregory Stark
• Re: SELECT * FROM table is too slow
  • From: Steinar H. Gunderson
• Re: libgcc double-free, backend won't die
  • From: Craig James
• Re: update 600000 rows
  • From: Merlin Moncure
• Re: SELECT * FROM table is too slow
  • From: Joshua D. Drake
• SELECT * FROM table is too slow
  • From: Adam PAPAI
• Re: libgcc double-free, backend won't die
  • From: Gregory Stark
• Re: libgcc double-free, backend won't die
  • From: Tom Lane
• Re: libgcc double-free, backend won't die
  • From: James Mansion
• Re: update 600000 rows
  • From: H. Hall
• Re: RAID arrays and performance
  • From: Bruce Momjian
• Re: update 600000 rows
  • From: andrew
• Re: update 600000 rows
  • From: Greg Smith
• Re: update 600000 rows
  • From: Loïc Marteau
• Re: explanation for seeks in VACUUM
  • From: Jeff Davis
• Re: update 600000 rows
  • From: Steve Crawford
• update 600000 rows
  • From: okparanoid
• Re: explanation for seeks in VACUUM
  • From: Tom Lane
• Re: VACUUM FREEZE output more than double input
  • From: Tom Lane
• Re: viewing source code
  • From: Alvaro Herrera
• Re: viewing source code
  • From: Jonah H. Harris
• Re: viewing source code
  • From: Roberts, Jon
• Re: viewing source code
  • From: Andreas Kretschmer
• Re: viewing source code
  • From: Jonah H. Harris
• Re: explanation for seeks in VACUUM (8.2.4)
  • From: Jeff Davis
• explanation for seeks in VACUUM
  • From: Jeff Davis
• Re: viewing source code
  • From: Bill Moran
• VACUUM FREEZE output more than double input
  • From: Kevin Grittner
• Re: viewing source code
  • From: Alvaro Herrera
• Large Objects and Toast
  • From: Campbell, Lance
• Re: viewing source code
  • From: Joshua D. Drake
• Re: Heavy write activity on first vacuum of fresh TOASTa
  • From: Matthew
• Re: Heavy write activity on first vacuum of fresh TOASTa
  • From: Tom Lane
• Re: viewing source code
  • From: Bill Moran
• Re: Heavy write activity on first vacuum of fresh TOAST data
  • From: Kevin Grittner
• Re: Heavy write activity on first vacuum of fresh TOASTa
  • From: Matthew
• Re: viewing source code
  • From: Roberts, Jon
• Re: viewing source code
  • From: Bill Moran
• Re: Heavy write activity on first vacuum of fresh TOAST data
  • From: Kevin Grittner
• viewing source code
  • From: Roberts, Jon
• Re: Limited performance on multi core server
  • From: Heikki Linnakangas
• Re: Need help on parameters and their values to tune the postgresql database
  • From: Heikki Linnakangas
• Re: Heavy write activity on first vacuum of fresh TOAST data
  • From: Tom Lane
• Re: Heavy write activity on first vacuum of fresh TOAST data
  • From: Russell Smith
• Re: Heavy write activity on first vacuum of fresh TOAST data
  • From: Kevin Grittner
• Re: Heavy write activity on first vacuum of fresh TOAST data
  • From: Simon Riggs
• Re: Heavy write activity on first vacuum of fresh TOAST data
  • From: Kevin Grittner
• Re: Putting files into fields in a table
  • From: Campbell, Lance
• Re: Putting files into fields in a table
  • From: Erik Jones
• Re: Putting files into fields in a table
  • From: Alvaro Herrera
• Re: Putting files into fields in a table
  • From: Campbell, Lance
• Re: Putting files into fields in a table
  • From: Alexander Staubo
• Re: Heavy write activity on first vacuum of fresh TOAST data
  • From: Simon Riggs
• Putting files into fields in a table
  • From: Campbell, Lance
• Re: Heavy write activity on first vacuum of fresh TOAST data
  • From: Tom Lane
• Re: Heavy write activity on first vacuum of fresh TOAST data
  • From: Simon Riggs
• Re: Heavy write activity on first vacuum of fresh TOAST data
  • From: Kevin Grittner
• Re: Heavy write activity on first vacuum of fresh TOAST data
  • From: Alvaro Herrera
• Re: Limited performance on multi core server
  • From: Joshua D. Drake
• Re: Heavy write activity on first vacuum of fresh TOAST data
  • From: Simon Riggs
• Re: Heavy write activity on first vacuum of fresh TOAST data
  • From: Kevin Grittner
• Re: Heavy write activity on first vacuum of fresh TOAST data
  • From: Tom Lane
• Re: Heavy write activity on first vacuum of fresh TOAST data
  • From: Kevin Grittner
• Re: Limited performance on multi core server
  • From: Simon Riggs
• Re: Heavy write activity on first vacuum of fresh TOAST data
  • From: Simon Riggs
• Heavy write activity on first vacuum of fresh TOAST data
  • From: Kevin Grittner
• Re: Index on VARCHAR with text_pattern_ops inside PL/PGSQL procedure.
  • From: Piotr Gasidło
• Re: Limited performance on multi core server
  • From: Joshua D. Drake
• Re: Limited performance on multi core server
  • From: Joshua D. Drake
• Re: URI to kind of a benchmark
  • From: Stefan Kaltenbrunner
• Re: Limited performance on multi core server
  • From: Sven Geisler
• Re: Limited performance on multi core server
  • From: Matthew Lunnon
• URI to kind of a benchmark
  • From: Harald Armin Massa
• Re: Limited performance on multi core server
  • From: Sven Geisler
• Re: Limited performance on multi core server
  • From: Sven Geisler
• Re: Limited performance on multi core server
  • From: Matthew Lunnon
• Re: Limited performance on multi core server
  • From: Matthew Lunnon
• Re: Limited performance on multi core server
  • From: Sven Geisler
• Re: Limited performance on multi core server
  • From: Sven Geisler
• Re: Limited performance on multi core server
  • From: Greg Smith
• Re: Limited performance on multi core server
  • From: Claus Guttesen
• Re: Limited performance on multi core server
  • From: Matthew Lunnon
• Re: Limited performance on multi core server
  • From: Matthew Lunnon
• Re: Limited performance on multi core server
  • From: Matthew Lunnon
• Re: Limited performance on multi core server
  • From: Sven Geisler
• Re: Limited performance on multi core server
  • From: Claus Guttesen
• Re: Limited performance on multi core server
  • From: Claus Guttesen
• Re: Limited performance on multi core server
  • From: Steinar H. Gunderson
• Limited performance on multi core server
  • From: Matthew Lunnon
• Need help on parameters and their values to tune the postgresql database
  • From: Bebarta, Simanchala
• Re: database tuning
  • From: Joshua D. Drake
• Re: database tuning
  • From: Michael Stone
• Re: database tuning
  • From: Greg Smith
• Re: database tuning
  • From: kelvan
• Re: TB-sized databases
  • From: Simon Riggs
• Re: database tuning
  • From: Richard Huxton
• Re: database tuning
  • From: Erik Jones
• Re: database tuning
  • From: Scott Marlowe
• Re: database tuning
  • From: Alvaro Herrera
• Re: database tuning
  • From: kelvan
• Re: libgcc double-free, backend won't die
  • From: Tom Lane
• Re: libgcc double-free, backend won't die
  • From: Gregory Stark
• Re: libgcc double-free, backend won't die
  • From: Craig James
• Re: libgcc double-free, backend won't die
  • From: Joshua D. Drake
• Re: libgcc double-free, backend won't die
  • From: Tom Lane
• Re: libgcc double-free, backend won't die
  • From: Tom Lane
• Re: libgcc double-free, backend won't die
  • From: Tom Lane
• Re: libgcc double-free, backend won't die
  • From: Magnus Hagander
• Re: libgcc double-free, backend won't die
  • From: Craig James
• Re: libgcc double-free, backend won't die
  • From: Craig James
• Re: libgcc double-free, backend won't die
  • From: Tom Lane
• Re: libgcc double-free, backend won't die
  • From: Alvaro Herrera
• Re: libgcc double-free, backend won't die
  • From: Craig James
• Re: libgcc double-free, backend won't die
  • From: Alvaro Herrera
• Re: libgcc double-free, backend won't die
  • From: Craig James
• Re: libgcc double-free, backend won't die
  • From: Alvaro Herrera
• Re: libgcc double-free, backend won't die
  • From: Craig James
• Re: libgcc double-free, backend won't die
  • From: Tom Lane
• Re: libgcc double-free, backend won't die
  • From: Craig James
• Slow Query
  • From: Pallav Kalva
• Is it spam or not?
  • From: Manolo _
• Re: Benchmarking PG
  • From: Heikki Linnakangas
• Is it spam or not?
  • From: Manolo _
• Re: Benchmarking PG
  • From: Manolo _
• Re: libgcc double-free, backend won't die
  • From: Alvaro Herrera
• Re: Benchmarking PG
  • From: Josh Tolley
• Benchmarking PG
  • From: Manolo _
• libgcc double-free, backend won't die
  • From: Craig James
• Re: database tuning
  • From: Greg Smith
• Fwd: Re: database tuning
  • From: Kevin Grittner
• Re: database tuning
  • From: Kevin Grittner
• Re: database tuning
  • From: kelvan
• Re: database tuning
  • From: Scott Marlowe
• Re: Index on VARCHAR with text_pattern_ops inside PL/PGSQL procedure.
  • From: Pavel Stehule
• Re: Index on VARCHAR with text_pattern_ops inside PL/PGSQL procedure.
  • From: Richard Huxton