Postgres Performance Date Index

• Thread Index

• Re: scalablility problem
  • From: Xiaoning Ding
• Re: scalablility problem
  • From: Tom Lane
• Re: scalablility problem
  • From: Dave Dutcher
• scalablility problem
  • From: Xiaoning Ding
• Re: Shared buffers, db transactions commited, and write IO on Solaris
  • From: Erik Jones
• Re: Wrong plan sequential scan instead of an index one
  • From: Tom Lane
• Re: Weird performance drop
  • From: Dave Dutcher
• Re: Shared buffers, db transactions commited, and write IO on Solaris
  • From: Dimitri
• Re: Shared buffers, db transactions commited, and write IO on Solaris
  • From: Erik Jones
• Re: Wrong plan sequential scan instead of an index one
  • From: Matteo Beccati
• Re: Shared buffers, db transactions commited, and write IO on Solaris
  • From: Dimitri
• Re: Wrong plan sequential scan instead of an index one
  • From: Richard Huxton
• Re: Wrong plan sequential scan instead of an index one
  • From: Gaetano Mendola
• Re: Wrong plan sequential scan instead of an index one
  • From: Gaetano Mendola
• Re: Wrong plan sequential scan instead of an index one
  • From: Michael Fuhr
• Re: Wrong plan sequential scan instead of an index one
  • From: Michael Fuhr
• Re: Wrong plan sequential scan instead of an index one
  • From: ismo . tuononen
• Re: Wrong plan sequential scan instead of an index one
  • From: Richard Huxton
• Re: Wrong plan sequential scan instead of an index one
  • From: Gaetano Mendola
• Re: Wrong plan sequential scan instead of an index one
  • From: Gaetano Mendola
• Re: Wrong plan sequential scan instead of an index one
  • From: Richard Huxton
• Re: Wrong plan sequential scan instead of an index one
  • From: Claus Guttesen
• Wrong plan sequential scan instead of an index one
  • From: Gaetano Mendola
• Re: Planner doing seqscan before indexed join
  • From: Marc Mamin
• Re: Scaling SELECT:s with the number of disks on a stripe
  • From: Marc Mamin
• Re: Weird performance drop
  • From: Vincenzo Romano
• Re: Shared buffers, db transactions commited, and write IO on Solaris
  • From: Erik Jones
• Scaling SELECT:s with the number of disks on a stripe
  • From: Peter Schuller
• Re: Shared buffers, db transactions commited, and write IO on Solaris
  • From: Greg Smith
• Re: Shared buffers, db transactions commited, and write IO on Solaris
  • From: Erik Jones
• Re: Sunfire X4500 recommendations
  • From: david
• Re: Shared buffers, db transactions commited, and write IO on Solaris
  • From: Josh Berkus
• Re: Planner doing seqscan before indexed join
  • From: Dave Dutcher
• Re: Weird performance drop
  • From: Dave Dutcher
• Re: Shared buffers, db transactions commited, and write IO on Solaris
  • From: Dimitri
• Re: Shared buffers, db transactions commited, and write IO on Solaris
  • From: Erik Jones
• Re: Shared buffers, db transactions commited, and write IO on Solaris
  • From: Tom Lane
• Re: Shared buffers, db transactions commited, and write IO on Solaris
  • From: Erik Jones
• Weird performance drop
  • From: Vincenzo Romano
• Re: Shared buffers, db transactions commited, and write IO on Solaris
  • From: dimitri k
• Re: Shared buffers, db transactions commited, and write IO on Solaris
  • From: Erik Jones
• Re: Shared buffers, db transactions commited, and write IO on Solaris
  • From: Tom Lane
• Re: Sunfire X4500 recommendations
  • From: Matt Smiley
• Planner doing seqscan before indexed join
  • From: Dan Harris
• Shared buffers, db transactions commited, and write IO on Solaris
  • From: Erik Jones
• Re: Improving performance on system catalog
  • From: Daniel Cristian Cruz
• Re: Improving performance on system catalog
  • From: Tom Lane
• Re: Improving performance on system catalog
  • From: Joshua D. Drake
• Re: Improving performance on system catalog
  • From: Daniel Cristian Cruz
• Re: Improving performance on system catalog
  • From: chris smith
• Improving performance on system catalog
  • From: Daniel Cristian Cruz
• Re: Sunfire X4500 recommendations
  • From: david
• Re: Sunfire X4500 recommendations
  • From: Matt Smiley
• Re: How to enable jdbc???
  • From: Joshua D. Drake
• How to enable jdbc???
  • From: Michael Dengler
• Re: [GENERAL] ERROR: out of shared memory
  • From: Tom Lane
• Re: [GENERAL] ERROR: out of shared memory
  • From: Merlin Moncure
• Re: Nested Loop
  • From: Ragnar
• Re: Nested Loop
  • From: Gauri Kanekar
• Re: [GENERAL] ERROR: out of shared memory
  • From: Tom Lane
• Re: Nested Loop
  • From: Ragnar
• Re: Nested Loop
  • From: Dave Dutcher
• Re: Nested Loop
  • From: Gauri Kanekar
• Re: Nested Loop
  • From: Michael Fuhr
• Re: Sunfire X4500 recommendations
  • From: Dimitri
• Nested Loop
  • From: Gauri Kanekar
• Re: OT: Munin (was Re: Determining server load from client)
  • From: Stefan Kaltenbrunner
• Re: OT: Munin (was Re: Determining server load from client)
  • From: CAJ CAJ
• Re: Optimization postgresql 8.1.4 FC 6 X64 ?
  • From: Dave Cramer
• Re: [HACKERS] EXISTS optimization
  • From: Martijn van Oosterhout
• Re: Optimization postgresql 8.1.4 FC 6 X64 ?
  • From: Heikki Linnakangas
• Optimization postgresql 8.1.4 FC 6 X64 ?
  • From: amrit angsusingh
• Re: [HACKERS] EXISTS optimization
  • From: Kevin Grittner
• Re: [HACKERS] EXISTS optimization
  • From: Tom Lane
• Re: [HACKERS] EXISTS optimization
  • From: Kevin Grittner
• Re: [HACKERS] EXISTS optimization
  • From: Kevin Grittner
• Re: [HACKERS] EXISTS optimization
  • From: Martijn van Oosterhout
• Re: [HACKERS] EXISTS optimization
  • From: Kevin Grittner
• Re: Strange left outer join performance issue
  • From: Tom Lane
• Re: Strange left outer join performance issue
  • From: Noah M. Daniels
• Re: Strange left outer join performance issue
  • From: Tom Lane
• Re: [HACKERS] EXISTS optimization
  • From: Tom Lane
• Re: Strange left outer join performance issue
  • From: Noah M. Daniels
• Optimization pg 8.14 and postgresql.conf
  • From: amrit angsusingh
• Re: Strange left outer join performance issue
  • From: Daniel Cristian Cruz
• Strange left outer join performance issue
  • From: Noah M. Daniels
• EXISTS optimization
  • From: Kevin Grittner
• Re: Parallel Vacuum
  • From: Michael Stone
• Re: Performance of count(*)
  • From: Tino Wildenhain
• Re: Vacuum full is slow
  • From: Scott Marlowe
• Re: linux - server configuration for small database
  • From: Joshua D. Drake
• Re: Parallel Vacuum
  • From: Dimitri
• Re: linux - server configuration for small database
  • From: Tom Lane
• Re: Sunfire X4500 recommendations
  • From: Matt Smiley
• Re: Performance of count(*)
  • From: Michael Stone
• linux - server configuration for small database
  • From: Paolo Negri
• Re: Performance of count(*)
  • From: Tino Wildenhain
• Re: Sunfire X4500 recommendations
  • From: Dimitri
• Sunfire X4500 recommendations
  • From: Matt Smiley
• Re: Performance of count(*)
  • From: Tino Wildenhain
• Re: Performance of count(*)
  • From: Tino Wildenhain
• Re: Performance of count(*)
  • From: Tom Lane
• Re: Performance of count(*)
  • From: Craig A. James
• Re: Performance of count(*)
  • From: Michael Stone
• Re: Parallel Vacuum
  • From: Michael Stone
• Re: Performance of count(*)
  • From: Tom Lane
• Re: Performance of count(*)
  • From: Steve Atkins
• Re: Performance of count(*)
  • From: Guido Neitzer
• Re: Performance of count(*)
  • From: Merlin Moncure
• Re: Potential memory usage issue [resolved]
  • From: David Brain
• Re: Parallel Vacuum
  • From: Dimitri
• Re: Performance of count(*)
  • From: Craig A. James
• Re: Performance of count(*)
  • From: Steve Atkins
• Re: Performance of count(*)
  • From: Craig A. James
• Re: Performance of count(*)
  • From: Michael Stone
• Re: Performance of count(*)
  • From: Tino Wildenhain
• Re: Performance of count(*)
  • From: Craig A. James
• Re: Parallel Vacuum
  • From: Michael Stone
• Re: Potential memory usage issue
  • From: Bill Moran
• Re: Performance of count(*)
  • From: Craig A. James
• Re: Potential memory usage issue
  • From: David Brain
• Re: Performance of count(*)
  • From: Mario Weilguni
• Re: Performance of count(*)
  • From: Brian Hurt
• Re: Parallel Vacuum
  • From: Alvaro Herrera
• Re: Performance of count(*)
  • From: Carlos Moreno
• Re: Parallel Vacuum
  • From: Dimitri
• Re: Potential memory usage issue
  • From: Tom Lane
• Re: Performance of count(*)
  • From: Tino Wildenhain
• Re: Performance of count(*)
  • From: Craig A. James
• Re: Performance of count(*)
  • From: Andreas Kostyrka
• Re: Parallel Vacuum
  • From: Alvaro Herrera
• Re: Parallel Vacuum
  • From: Dimitri
• Re: Performance of count(*)
  • From: mark
• Re: Performance of count(*)
  • From: Luke Lonergan
• Re: Performance of count(*)
  • From: Michael Stone
• Re: Performance of count(*)
  • From: Michael Fuhr
• Re: Lower Random Access Time vs RAID 0 / 1
  • From: Ron
• Re: Performance of count(*)
  • From: Mario Weilguni
• Re: Performance of count(*)
  • From: Jonah H. Harris
• Re: Performance of count(*)
  • From: Michael Stone
• Re: Parallel Vacuum
  • From: Alvaro Herrera
• Re: Performance of count(*)
  • From: Merlin Moncure
• Parallel Vacuum
  • From: Dimitri
• Re: Performance of count(*)
  • From: Mario Weilguni
• Re: Potential memory usage issue
  • From: Bill Moran
• Re: Potential memory usage issue
  • From: David Brain
• Re: Potential memory usage issue
  • From: Bill Moran
• Re: Performance of count(*)
  • From: Bill Moran
• Re: Performance of count(*)
  • From: Andreas Kostyrka
• Potential memory usage issue
  • From: David Brain
• Re: Performance of count(*)
  • From: Andreas Tille
• Re: Performance of count(*)
  • From: ismo . tuononen
• Re: Performance of count(*)
  • From: ismo . tuononen
• Re: Performance of count(*)
  • From: Albert Cervera Areny
• Re: Performance of count(*)
  • From: Andreas Kostyrka
• Performance of count(*)
  • From: Andreas Tille
• Lower Random Access Time vs RAID 0 / 1
  • From: Michael Ben-Nes
• Re: OT: Munin (was Re: Determining server load from client)
  • From: Erik Jones
• Re: OT: Munin (was Re: Determining server load from client)
  • From: Tobias Brox
• Re: OT: Munin (was Re: Determining server load from client)
  • From: Erik Jones
• Re: OT: Munin (was Re: Determining server load from client)
  • From: Richard Huxton
• Re: OT: Munin (was Re: Determining server load from client)
  • From: Tobias Brox
• OT: Munin (was Re: Determining server load from client)
  • From: Richard Huxton
• Re: Determining server load from client
  • From: Jim Buttafuoco
• Re: Determining server load from client
  • From: Dan Harris
• Re: Determining server load from client
  • From: Joe Healy
• Re: Determining server load from client
  • From: Craig A. James
• Determining server load from client
  • From: Dan Harris
• Re: Horrible trigger performance after upgrade 8.0.12 -> 8.2.3
  • From: Tom Lane
• Horrible trigger performance after upgrade 8.0.12 -> 8.2.3
  • From: Joseph S
• Re: SATA RAID: Promise vs. 3ware
  • From: Ron
• Re: SATA RAID: Promise vs. 3ware
  • From: Dave Cramer
• Re: SATA RAID: Promise vs. 3ware
  • From: Dave Cramer
• Re: how small to split a table?
  • From: Vivek Khera
• Re: SATA RAID: Promise vs. 3ware
  • From: Joshua D. Drake
• Re: how small to split a table?
  • From: Heiko W.Rupp
• how small to split a table?
  • From: Vivek Khera
• Re: SATA RAID: Promise vs. 3ware
  • From: Magnus Hagander
• Re: SATA RAID: Promise vs. 3ware
  • From: Merlin Moncure
• SATA RAID: Promise vs. 3ware
  • From: Ireneusz Pluta
• Re: Vacuum full is slow
  • From: Shoaib Mir
• Re: Vacuum full is slow
  • From: Ruben Rubio
• Re: text equality worse than pattern matching (v8.1.8)
  • From: Vincenzo Romano
• Re: Vacuum full is slow
  • From: Heikki Linnakangas
• Vacuum full is slow
  • From: Ruben Rubio
• Re: function call vs staright query
  • From: Vincenzo Romano
• Re: function call vs staright query
  • From: Tom Lane
• Re: Performance Tuning and Disk Cache
  • From: Michael Stone
• Re: Performance Tuning and Disk Cache
  • From: Rangarajan Vasudevan
• Re: Performance Tuning and Disk Cache
  • From: David Boreham
• Re: Performance Tuning and Disk Cache
  • From: hubert depesz lubaczewski
• Performance Tuning and Disk Cache
  • From: Barry Moore
• Re: text equality worse than pattern matching (v8.1.8)
  • From: hubert depesz lubaczewski
• text equality worse than pattern matching (v8.1.8)
  • From: Vincenzo Romano
• Re: function call vs staright query
  • From: Vincenzo Romano
• function call vs staright query
  • From: Vincenzo Romano
• Re: Postgres batch write very slow - what to do
  • From: hubert depesz lubaczewski
• Re: PostgreSQL 8.2.3 VACUUM Timings/Performance
  • From: Bruce McAlister
• Re: Postgres batch write very slow - what to do
  • From: Joshua D. Drake
• Re: Postgres batch write very slow - what to do
  • From: Carlos Moreno
• unsubscribe
  • From: cedric
• Re: Determine dead tuples size
  • From: Tom Lane
• Re: Postgres batch write very slow - what to do
  • From: Joshua D. Drake
• Re: Postgres batch write very slow - what to do
  • From: Merlin Moncure
• Re: Postgres batch write very slow - what to do
  • From: Merlin Moncure
• Re: Postgres batch write very slow - what to do
  • From: Merlin Moncure
• Re: Determine dead tuples size
  • From: Heikki Linnakangas
• Re: Determine dead tuples size
  • From: Alexey Romanchuk
• Re: Postgres batch write very slow - what to do
  • From: Tom Lane
• Re: Dispatch-Merge pattern
  • From: Steve Atkins
• Re: Postgres batch write very slow - what to do
  • From: femski
• Re: Determine dead tuples size
  • From: Michael Fuhr
• Re: Determine dead tuples size
  • From: Daniel Cristian Cruz
• unsubscribe
  • From: Neelam Goyal
• Determine dead tuples size
  • From: Alexey Romanchuk
• Re: Postgres batch write very slow - what to do
  • From: Merlin Moncure
• Re: Postgres batch write very slow - what to do
  • From: femski
• Re: Postgres batch write very slow - what to do
  • From: Merlin Moncure
• Re: Postgres batch write very slow - what to do
  • From: femski
• Re: PostgreSQL 8.2.3 VACUUM Timings/Performance
  • From: Anton Melser
• Re: PostgreSQL in virtual machine
  • From: Cosimo Streppone
• test ...please ignore
  • From: Dengler, Michael
• Re: Autocommit in libpq
  • From: Tom Lane
• Re: Autocommit in libpq
  • From: Dengler, Michael
• Re: Postgres batch write very slow - what to do
  • From: Tom Lane
• Re: Postgres batch write very slow - what to do
  • From: Heikki Linnakangas
• Re: Execution plan changed after upgrade from 7.3.9 to 8.2.3
  • From: vincent.moreau
• Re: Postgres batch write very slow - what to do
  • From: Tom Lane
• Re: Autocommit in libpq
  • From: Joshua D. Drake
• Re: Autocommit in libpq
  • From: Heikki Linnakangas
• Autocommit in libpq
  • From: Dengler, Michael
• Re: Execution plan changed after upgrade from 7.3.9 to 8.2.3
  • From: Tom Lane
• Re: Execution plan changed after upgrade from 7.3.9 to 8.2.3
  • From: Dave Dutcher
• Re: Execution plan changed after upgrade from 7.3.9 to 8.2.3
  • From: vincent.moreau
• Re: Execution plan changed after upgrade from 7.3.9 to 8.2.3
  • From: vincent.moreau
• Re: Execution plan changed after upgrade from 7.3.9 to 8.2.3
  • From: Alvaro Herrera
• Dispatch-Merge pattern
  • From: James Riordan
• Re: Execution plan changed after upgrade from 7.3.9 to 8.2.3
  • From: Richard Huxton
• Re: Execution plan changed after upgrade from 7.3.9 to 8.2.3
  • From: vincent.moreau
• Re: Execution plan changed after upgrade from 7.3.9 to 8.2.3
  • From: Dave Dutcher
• Re: Execution plan changed after upgrade from 7.3.9 to 8.2.3
  • From: Alvaro Herrera
• Re: Postgres batch write very slow - what to do
  • From: femski
• Re: Postgres batch write very slow - what to do
  • From: Merlin Moncure
• Re: Execution plan changed after upgrade from 7.3.9 to 8.2.3
  • From: vincent.moreau
• Re: Execution plan changed after upgrade from 7.3.9 to 8.2.3
  • From: Richard Huxton
• Re: Execution plan changed after upgrade from 7.3.9 to 8.2.3
  • From: vincent.moreau
• Re: Postgres batch write very slow - what to do
  • From: Heikki Linnakangas
• Postgres batch write very slow - what to do
  • From: femski
• Re: Execution plan changed after upgrade from 7.3.9 to 8.2.3
  • From: Michael Fuhr
• Execution plan changed after upgrade from 7.3.9 to 8.2.3
  • From: vincent.moreau
• Re: PostgreSQL in virtual machine
  • From: Harald Armin Massa
• PostgreSQL in virtual machine
  • From: Andreas Tille
• [no subject]
  • From: Unknown
• Re: configuring new server / many slow disks?
  • From: Scott Marlowe
• Re: configuring new server / many slow disks?
  • From: Axel Rau
• Re: Deceiding which index to use
  • From: Richard Huxton
• Re: Deceiding which index to use
  • From: Richard Huxton
• Re: Deceiding which index to use
  • From: Mezei Zoltán
• Re: Deceiding which index to use
  • From: Mezei Zoltán
• Re: Deceiding which index to use
  • From: Alvaro Herrera
• Re: Deceiding which index to use
  • From: Richard Huxton
• Re: Deceiding which index to use
  • From: Mezei Zoltán
• Re: Deceiding which index to use
  • From: Richard Huxton
• Re: Deceiding which index to use
  • From: Mezei Zoltán
• Re: Deceiding which index to use
  • From: Richard Huxton
• Re: Deceiding which index to use
  • From: Mezei Zoltán
• Re: Deceiding which index to use
  • From: Richard Huxton
• Re: Any advantage to integer vs stored date w. timestamp
  • From: Zoolin Lin
• Deceiding which index to use
  • From: Mezei Zoltán
• Re: configuring new server / many slow disks?
  • From: Richard Huxton
• Re: configuring new server / many slow disks?
  • From: Axel Rau
• Re: PostgreSQL 8.2.3 VACUUM Timings/Performance
  • From: Bruce McAlister
• Re: compact flash disks?
  • From: James Mansion
• Re: Question about PGSQL functions
  • From: Steve
• Re: help
  • From: Gavin Sherry
• Re: Question about PGSQL functions
  • From: Heikki Linnakangas
• Question about PGSQL functions
  • From: Steve
• Re: strange performance regression between 7.4 and 8.1
  • From: Craig A. James
• Re: compact flash disks?
  • From: Merlin Moncure
• Re: strange performance regression between 7.4 and 8.1
  • From: Carlos Moreno
• Re: strange performance regression between 7.4 and 8.1
  • From: Carlos Moreno
• Re: strange performance regression between 7.4 and 8.1
  • From: Ron
• Re: function performance vs in-line sql
  • From: Schwarz, Karl
• Re: compact flash disks?
  • From: Ron
• Re: strange performance regression between 7.4 and 8.1
  • From: Craig A. James
• Re: function performance vs in-line sql
  • From: Heikki Linnakangas
• Re: function performance vs in-line sql
  • From: Richard Huxton
• function performance vs in-line sql
  • From: Schwarz, Karl
• Re:
  • From: Jeff Cole
• Re: compact flash disks?
  • From: Merlin Moncure
• Re: strange performance regression between 7.4 and 8.1
  • From: Rodrigo Madera
• configuring new server / many slow disks?
  • From: Axel Rau
• Re: compact flash disks?
  • From: Magnus Hagander
• Re: compact flash disks?
  • From: James Mansion
• Re: Any advantage to integer vs stored date w. timestamp
  • From: Shane Ambler
• Re: Any advantage to integer vs stored date w. timestamp
  • From: Zoolin Lin
• Re: [kris@xxxxxxxxxxxxxx: Progress on scaling of FreeBSD on 8 CPU systems]
  • From: Stefan Kaltenbrunner
• Re:
  • From: Tom Lane
• Re: compact flash disks?
  • From: cedric
• Re: compact flash disks?
  • From: Csaba Nagy
• Re: compact flash disks?
  • From: Carlos Moreno
• Re: compact flash disks?
  • From: Ron
• Re: Any advantage to integer vs stored date w. timestamp
  • From: Richard Huxton
• Re: Any advantage to integer vs stored date w. timestamp
  • From: Zoolin Lin
• Re: compact flash disks?
  • From: Florian Weimer
• Re: Any advantage to integer vs stored date w. timestamp
  • From: Richard Huxton
• Re: When the Record Got Updated.
  • From: A. Kretschmer
• When the Record Got Updated.
  • From: Gauri Kanekar
• Re: compact flash disks?
  • From: Merlin Moncure
• compact flash disks?
  • From: James Mansion
• problem with wrong query planning and ineffective statistics
  • From: Paolo Negri
• Any advantage to integer vs stored date w. timestamp
  • From: Zoolin Lin
• Re:
  • From: Jeff Cole
• Re: Automated test-suite for Postgres
  • From: Heikki Linnakangas
• Re: strange performance regression between 7.4 and 8.1
  • From: Alex Deucher
• Re: Insert performance
  • From: Carlos Moreno
• Automated test-suite for Postgres
  • From: Neelam Goyal
• Re: strange performance regression between 7.4 and 8.1
  • From: Ron
• Re: Estimate the size of the SQL file generated by pg_dump utility
  • From: Richard Troy
• Re:
  • From: Tom Lane
• Re: Insert performance
  • From: Csaba Nagy
• Re: Insert performance
  • From: Carlos Moreno
• Re: Insert performance
  • From: hatman
• Re:
  • From: Jeff Cole
• Re: Insert performance
  • From: hatman
• Re: Estimate the size of the SQL file generated by pg_dump utility
  • From: Tom Lane
• Re: strange performance regression between 7.4 and 8.1
  • From: Alex Deucher
• Re: Estimate the size of the SQL file generated by pg_dump utility
  • From: Claus Guttesen
• Re: Estimate the size of the SQL file generated by pg_dump utility
  • From: Craig A. James
• Re: Estimate the size of the SQL file generated by pg_dump utility
  • From: Bill Moran
• Re: Insert performance
  • From: Andreas Kostyrka
• Re: Insert performance
  • From: Richard Huxton
• Re: Insert performance
  • From: Andreas Kostyrka
• help
  • From: lissette
• Re: Insert performance
  • From: Richard Huxton
• Re: Insert performance
  • From: joël Winteregg
• Re: Insert performance
  • From: Richard Huxton
• Re: Insert performance
  • From: joël Winteregg
• Re: Hibernate left join
  • From: Richard Huxton
• Re: Insert performance
  • From: Richard Huxton
• Re: query slows down after vacuum analyze
  • From: ismo . tuononen
• Re: strange performance regression between 7.4 and 8.1
  • From: Guido Neitzer
• Re: strange performance regression between 7.4 and 8.1
  • From: Alex Deucher
• Re: Estimate the size of the SQL file generated by pg_dump utility
  • From: Bruce Momjian
• Re: Estimate the size of the SQL file generated by pg_dump utility
  • From: Bricklen Anderson
• Re: strange performance regression between 7.4 and 8.1
  • From: Guido Neitzer
• Re:
  • From: Tom Lane
• Re: Opinions on Raid
  • From: Steinar H. Gunderson
• query slows down after vacuum analyze
  • From: Jeff Cole
• Re: Estimate the size of the SQL file generated by pg_dump utility
  • From: Bruce Momjian
• [no subject]
  • From: Jeff Cole
• Re: Turning off Autovacuum
  • From: Steven Flatt
• Re: [kris@xxxxxxxxxxxxxx: Progress on scaling of FreeBSD on 8 CPU systems]
  • From: Arjen van der Meijden
• Re: [kris@xxxxxxxxxxxxxx: Progress on scaling of FreeBSD on 8 CPU systems]
  • From: Tom Lane
• Re: Turning off Autovacuum
  • From: Tomas Vondra
• Re: [kris@xxxxxxxxxxxxxx: Progress on scaling of FreeBSD on 8 CPU systems]
  • From: Stefan Kaltenbrunner
• Re: PostgreSQL 8.2.3 VACUUM Timings/Performance
  • From: Heikki Linnakangas
• Re: PostgreSQL 8.2.3 VACUUM Timings/Performance
  • From: Tom Lane
• Turning off Autovacuum
  • From: Steven Flatt
• Re: PostgreSQL 8.2.3 VACUUM Timings/Performance
  • From: Aidan Van Dyk
• Re: Estimate the size of the SQL file generated by pg_dump utility
  • From: A. Kretschmer
• Estimate the size of the SQL file generated by pg_dump utility
  • From: Ravindran G-TLS,Chennai.
• Re: PostgreSQL 8.2.3 VACUUM Timings/Performance
  • From: Heikki Linnakangas
• Re: PostgreSQL 8.2.3 VACUUM Timings/Performance
  • From: Bruce McAlister
• Re: which Xeon processors don't have the context switching problem
  • From: Geoffrey
• Re: PostgreSQL 8.2.3 VACUUM Timings/Performance
  • From: Heikki Linnakangas
• Re: Having performance problems with TSearch2
  • From: Ares
• PostgreSQL 8.2.3 VACUUM Timings/Performance
  • From: Bruce McAlister
• Re: [kris@xxxxxxxxxxxxxx: Progress on scaling of FreeBSD on 8 CPU systems]
  • From: Richard Huxton
• Re: [kris@xxxxxxxxxxxxxx: Progress on scaling of FreeBSD on 8 CPU systems]
  • From: Arjen van der Meijden
• Re: [kris@xxxxxxxxxxxxxx: Progress on scaling of FreeBSD on 8 CPU systems]
  • From: Stefan Kaltenbrunner
• Re: [kris@xxxxxxxxxxxxxx: Progress on scaling of FreeBSD on 8 CPU systems]
  • From: Arjen van der Meijden
• [no subject]
  • From: Unknown
• Re: Opinions on Raid
  • From: Arjen van der Meijden
• Re: Upgraded to 8.2.3 --- still having performance issues
  • From: Dennis Bjorklund
• Re: Performance Query
  • From: Tom Lane
• Re: Performance Query
  • From: Josh Berkus
• Re: strange performance regression between 7.4 and 8.1
  • From: Alex Deucher
• Re: stats collector process high CPU utilization
  • From: Joshua D. Drake
• Re: stats collector process high CPU utilization
  • From: Bruce Momjian
• Re: strange performance regression between 7.4 and 8.1
  • From: Jeff Frost
• Re: strange performance regression between 7.4 and 8.1
  • From: Guido Neitzer
• Re: strange performance regression between 7.4 and 8.1
  • From: Alex Deucher
• Re: strange performance regression between 7.4 and 8.1
  • From: Ron
• Re: Array indexes, GIN?
  • From: Jeff Davis
• Re: strange performance regression between 7.4 and 8.1
  • From: Alex Deucher
• Re: strange performance regression between 7.4 and 8.1
  • From: Alvaro Herrera
• Re: strange performance regression between 7.4 and 8.1
  • From: Anton Rommerskirchen
• Re: strange performance regression between 7.4 and 8.1
  • From: Ron
• Re: strange performance regression between 7.4 and 8.1
  • From: Scott Marlowe
• Re: [kris@xxxxxxxxxxxxxx: Progress on scaling of FreeBSD on 8 CPU systems]
  • From: Scott Marlowe
• Re: strange performance regression between 7.4 and 8.1
  • From: Alex Deucher
• Re: strange performance regression between 7.4 and 8.1
  • From: Tom Lane
• Re: strange performance regression between 7.4 and 8.1
  • From: Alex Deucher
• Re: [kris@xxxxxxxxxxxxxx: Progress on scaling of FreeBSD on 8 CPU systems]
  • From: Arjen van der Meijden
• Re: strange performance regression between 7.4 and 8.1
  • From: Ron
• Re: strange performance regression between 7.4 and 8.1
  • From: Alex Deucher
• Re: strange performance regression between 7.4 and 8.1
  • From: Ron
• Re: strange performance regression between 7.4 and 8.1
  • From: Alex Deucher
• Re: [kris@xxxxxxxxxxxxxx: Progress on scaling of FreeBSD on 8 CPU systems]
  • From: Alvaro Herrera
• Re: strange performance regression between 7.4 and 8.1
  • From: Carlos Moreno
• Re: stats collector process high CPU utilization
  • From: Magnus Hagander
• Re: Improving query performance
  • From: David Leangen
• Re: strange performance regression between 7.4 and 8.1
  • From: Florian Weimer
• Re: Array indexes, GIN?
  • From: Adam L Beberg
• Hibernate left join
  • From: hytech . qa
• Re: Array indexes, GIN?
  • From: Oleg Bartunov
• Re: Improving query performance
  • From: Tom Lane
• Re: Array indexes, GIN?
  • From: Josh Berkus
• Array indexes, GIN?
  • From: Adam L Beberg
• Improving query performance
  • From: David Leangen
• Re: strange performance regression between 7.4 and 8.1
  • From: Alex Deucher
• Re: strange performance regression between 7.4 and 8.1
  • From: Joshua D. Drake
• Re: strange performance regression between 7.4 and 8.1
  • From: Alex Deucher
• Re: strange performance regression between 7.4 and 8.1
  • From: Jeff Frost
• Re: strange performance regression between 7.4 and 8.1
  • From: Alex Deucher
• Re: strange performance regression between 7.4 and 8.1
  • From: Joshua D. Drake
• Re: strange performance regression between 7.4 and 8.1
  • From: Alex Deucher
• Re: stats collector process high CPU utilization
  • From: Tom Lane
• Re: stats collector process high CPU utilization
  • From: Merlin Moncure
• Re: strange performance regression between 7.4 and 8.1
  • From: Ron
• Re: strange performance regression between 7.4 and 8.1
  • From: Jeff Frost
• Re: strange performance regression between 7.4 and 8.1
  • From: Jeff Frost
• Re: strange performance regression between 7.4 and 8.1
  • From: Alex Deucher
• Re: stats collector process high CPU utilization
  • From: Tom Lane
• Re: Identical Queries
  • From: Craig A. James
• Re: performances with Pentium D
  • From: hatman
• Re: Identical Queries
  • From: Stephan Szabo
• Re: strange performance regression between 7.4 and 8.1
  • From: Alex Deucher
• Re: strange performance regression between 7.4 and 8.1
  • From: Jeff Frost
• Re: stats collector process high CPU utilization
  • From: Merlin Moncure
• Re: strange performance regression between 7.4 and 8.1
  • From: Alex Deucher
• Re: strange performance regression between 7.4 and 8.1
  • From: Jeff Frost
• Re: strange performance regression between 7.4 and 8.1
  • From: Jeff Frost
• Re: strange performance regression between 7.4 and 8.1
  • From: Alex Deucher
• Re: Identical Queries
  • From: Chad Wagner
• Re: strange performance regression between 7.4 and 8.1
  • From: Alex Deucher
• Re: strange performance regression between 7.4 and 8.1
  • From: Jeff Frost
• Re: Identical Queries
  • From: Rob Schall
• Re: strange performance regression between 7.4 and 8.1
  • From: Joshua D. Drake
• strange performance regression between 7.4 and 8.1
  • From: Alex Deucher
• Re: stats collector process high CPU utilization
  • From: Benjamin Minshall
• strange performance regression between 7.4 and 8.1
  • From: Alex Deucher
• Re: stats collector process high CPU utilization
  • From: Tom Lane
• Re: Identical Queries
  • From: Stephan Szabo
• Re: increasing database connections
  • From: Joshua D. Drake
• Identical Queries
  • From: Rob Schall
• Performance Query
  • From: Abu Mushayeed
• Re: increasing database connections
  • From: Ron
• Re: increasing database connections
  • From: Florian Weimer
• Re: performances with Pentium D
  • From: Ben Trewern
• Re: increasing database connections
  • From: Magnus Hagander
• Re: increasing database connections
  • From: Mark Kirkwood
• Re: increasing database connections
  • From: Joshua D. Drake
• Re: increasing database connections
  • From: Jonah H. Harris
• increasing database connections
  • From: Shiva Sarna
• Re: Two hard drives --- what to do with them?
  • From: Bruno Wolff III
• Re: Two hard drives --- what to do with them?
  • From: Bruno Wolff III
• Re: Two hard drives --- what to do with them?
  • From: Bruno Wolff III
• Re: Upgraded to 8.2.3 --- still having performance issues
  • From: Carlos Moreno
• Re: Upgraded to 8.2.3 --- still having performance issues
  • From: Carlos Moreno
• Re: Upgraded to 8.2.3 --- still having performance issues
  • From: Rodrigo Gonzalez
• Re: Upgraded to 8.2.3 --- still having performance issues
  • From: Carlos Moreno
• Re: Upgraded to 8.2.3 --- still having performance issues
  • From: Carlos Moreno
• Re: Upgraded to 8.2.3 --- still having performance issues
  • From: Tom Lane
• Upgraded to 8.2.3 --- still having performance issues
  • From: Carlos Moreno
• performances with Pentium D
  • From: hatman
• Re: Writting a "search engine" for a pgsql DB
  • From: Dave Page
• Re: Writting a "search engine" for a pgsql DB
  • From: Oleg Bartunov
• Re: Writting a "search engine" for a pgsql DB
  • From: Dave Page
• Re: Writting a "search engine" for a pgsql DB
  • From: Steinar H. Gunderson
• Re: Writting a "search engine" for a pgsql DB
  • From: Dave Page
• Re: Writting a "search engine" for a pgsql DB
  • From: Magnus Hagander
• Re: Opinions on Raid
  • From: Geoff Tolley
• Re: Writting a "search engine" for a pgsql DB
  • From: Charles Sprickman
• Re: Writting a "search engine" for a pgsql DB
  • From: Chris
• Re: Two hard drives --- what to do with them?
  • From: Scott Marlowe
• Re: Two hard drives --- what to do with them?
  • From: Jeff Davis
• Re: Opinions on Raid
  • From: Scott Marlowe
• Re: [kris@xxxxxxxxxxxxxx: Anyone interested in improving postgresql scaling?]
  • From: Tom Lane
• Re: Two hard drives --- what to do with them?
  • From: Shane Ambler
• Re: Opinions on Raid
  • From: Joe Uhl
• [kris@xxxxxxxxxxxxxx: Anyone interested in improving postgresql scaling?]
  • From: Jim C. Nasby
• [kris@xxxxxxxxxxxxxx: Progress on scaling of FreeBSD on 8 CPU systems]
  • From: Jim C. Nasby
• Re: Postgres performance Linux vs FreeBSD
  • From: Andrew - Supernews
• Re: Opinions on Raid
  • From: Scott Marlowe
• Re: Opinions on Raid
  • From: mark
• Insert performance
  • From: hatman
• Re: Opinions on Raid
  • From: Ron
• Re: Two hard drives --- what to do with them?
  • From: Ben
• Re: Opinions on Raid
  • From: Stefan Kaltenbrunner
• Re: Writting a "search engine" for a pgsql DB
  • From: Dave Page
• Opinions on Raid
  • From: Joe Uhl
• Re: Writting a "search engine" for a pgsql DB
  • From: Magnus Hagander
• Re: Two hard drives --- what to do with them?
  • From: Peter Kovacs
• Re: Two hard drives --- what to do with them?
  • From: Shane Ambler
• Re: Two hard drives --- what to do with them?
  • From: Jeff Davis
• Re: Two hard drives --- what to do with them?
  • From: Peter Kovacs
• Re: Two hard drives --- what to do with them?
  • From: Jeff Davis
• Re: Writting a "search engine" for a pgsql DB
  • From: Charles Sprickman
• Re: Vacuumdb - Max_FSM_Pages Problem.
  • From: Ron
• Re: Writting a "search engine" for a pgsql DB
  • From: Jeff Davis
• Re: Writting a "search engine" for a pgsql DB
  • From: Mark Stosberg
• Re: Writting a "search engine" for a pgsql DB
  • From: Madison Kelly
• Re: Writting a "search engine" for a pgsql DB
  • From: Mark Stosberg
• Re: Writting a "search engine" for a pgsql DB
  • From: Magnus Hagander
• Re: Writting a "search engine" for a pgsql DB
  • From: Madison Kelly
• Re: [JDBC] does prepareThreshold work? forced to use old driver
  • From: Gene
• Re: Writting a "search engine" for a pgsql DB
  • From: Joshua D. Drake
• Re: Writting a "search engine" for a pgsql DB
  • From: Mark Stosberg
• Re: [JDBC] does prepareThreshold work? forced to use old driver
  • From: Dave Cramer
• Re: low memory usage reported by 'top' indicates poor tuning?
  • From: Mark Stosberg
• Re: low memory usage reported by 'top' indicates poor tuning?
  • From: Joshua D. Drake
• Re: Writting a "search engine" for a pgsql DB
  • From: Joshua D. Drake
• low memory usage reported by 'top' indicates poor tuning?
  • From: Mark Stosberg
• Re: [JDBC] does prepareThreshold work? forced to use old driver
  • From: Kris Jurka
• Writting a "search engine" for a pgsql DB
  • From: Madison Kelly
• does prepareThreshold work? forced to use old driver
  • From: Gene
• Re: Vacuumdb - Max_FSM_Pages Problem.
  • From: Peter Childs
• Vacuumdb - Max_FSM_Pages Problem.
  • From: Pallav Kalva
• Re: Server Startup Error
  • From: Richard Huxton
• Re: Server Startup Error
  • From: Rodrigo Gonzalez
• Re: Server Startup Error
  • From: Richard Huxton
• Re: Server Startup Error
  • From: Gauri Kanekar
• Re: Server Startup Error
  • From: Rodrigo Gonzalez
• Server Startup Error
  • From: Gauri Kanekar
• Re: pg_trgm performance
  • From: Oleg Bartunov
• Re: pg_trgm performance
  • From: Guillaume Smet
• Re: pg_trgm performance
  • From: Oleg Bartunov
• Re: pg_trgm performance
  • From: Guillaume Smet
• Re: Query Planner
  • From: Steinar H. Gunderson
• Query Planner
  • From: Gauri Kanekar
• Re: Very slow bytea data extraction
  • From: Richard Huxton
• invalid page header in block 428 of relation "pg_attribute"
  • From: ashok@xxxxxxxxxxxxx
• Re: Two hard drives --- what to do with them?
  • From: Peter Kovacs
• Re: Two hard drives --- what to do with them?
  • From: Alexander Staubo
• Re: Two hard drives --- what to do with them?
  • From: Tom Lane
• Two hard drives --- what to do with them?
  • From: Carlos Moreno
• Re: which Xeon processors don't have the context switching problem
  • From: Joshua D. Drake
• Re: pg_trgm performance
  • From: Steinar H. Gunderson
• Re: which Xeon processors don't have the context switching problem
  • From: Geoffrey
• Re: pg_trgm performance
  • From: Guillaume Smet
• Re: which Xeon processors don't have the context switching problem
  • From: Magnus Hagander
• Re: pg_trgm performance
  • From: Steinar H. Gunderson
• Re: pg_trgm performance
  • From: Guillaume Smet
• Re: long checkpoint_timeout
  • From: Jim C. Nasby
• Re: which Xeon processors don't have the context switching problem
  • From: Guillaume Smet
• Re: which Xeon processors don't have the context switching problem
  • From: Guillaume Smet
• Re: which Xeon processors don't have the context switching problem
  • From: Geoffrey
• Re: which Xeon processors don't have the context switching problem
  • From: Joshua D. Drake
• Re: which Xeon processors don't have the context switching problem
  • From: Geoffrey
• Re: which Xeon processors don't have the context switching problem
  • From: Josh Berkus
• Re: long checkpoint_timeout
  • From: Jeff Davis
• Re: long checkpoint_timeout
  • From: Jim C. Nasby
• Re: which Xeon processors don't have the context switching problem
  • From: Steinar H. Gunderson
• Re: which Xeon processors don't have the context switching problem
  • From: Alvaro Herrera
• Re: which Xeon processors don't have the context switching problem
  • From: Steinar H. Gunderson
• Re: which Xeon processors don't have the context switching problem
  • From: Claus Guttesen
• which Xeon processors don't have the context switching problem
  • From: Geoffrey
• long checkpoint_timeout
  • From: Jeff Davis
• Re: Recommended Initial Settings
  • From: Bill Moran
• Re: Very slow bytea data extraction
  • From: msmbarabino@xxxxxxxxxxx
• Re: Very slow bytea data extraction
  • From: msmbarabino@xxxxxxxxxxx
• Re: Recommended Initial Settings
  • From: Jim C. Nasby
• Re: Using the 8.2 autovacuum values with 8.1
  • From: Jim C. Nasby
• Re: Recommended Initial Settings
  • From: Richard Huxton
• Re: Recommended Initial Settings
  • From: Campbell, Lance
• Re: R: Very slow bytea data extraction
  • From: Merlin Moncure
• Re: Recommended Initial Settings
  • From: Richard Huxton
• Recommended Initial Settings
  • From: Campbell, Lance
• Re: R: Very slow bytea data extraction
  • From: Richard Huxton
• R: Very slow bytea data extraction
  • From: msmbarabino@xxxxxxxxxxx
• Re: Very slow bytea data extraction
  • From: Richard Huxton
• Very slow bytea data extraction
  • From: msmbarabino@xxxxxxxxxxx
• Re: Using the 8.2 autovacuum values with 8.1
  • From: Csaba Nagy
• Re: slow update on 1M rows (worse with indexes)
  • From: ismo . tuononen
• Using the 8.2 autovacuum values with 8.1
  • From: Mark Stosberg
• Re: Vacuum full very slow due to nonremovable dead rows...What makes the dead rows non-removable?
  • From: Steinar H. Gunderson
• Vacuum full very slow due to nonremovable dead rows...What makes the dead rows non-removable?
  • From: Barbara Cosentino
• Re: slow update on 1M rows (worse with indexes)
  • From: Joshua D. Drake
• Re: slow update on 1M rows (worse with indexes)
  • From: Steinar H. Gunderson
• slow update on 1M rows (worse with indexes)
  • From: Gabriel Biberian
• Re: Disable result buffering to frontend clients
  • From: Richard Huxton
• Disable result buffering to frontend clients
  • From: Konstantinos Krikellas
• Re: How to avoid vacuuming a huge logging table
  • From: D'Arcy J.M. Cain
• Re: How to avoid vacuuming a huge logging table
  • From: Greg Sabino Mullane
• Re: General advice on user functions
  • From: Dan Harris
• Re: Postgres performance Linux vs FreeBSD
  • From: Mark Kirkwood
• Re: Auto-Vacuum in 8.1 was ineffective for me. 8.2 may work better?
  • From: Alvaro Herrera
• Re: Auto-Vacuum in 8.1 was ineffective for me. 8.2 may work better?
  • From: Matthew T. O'Connor
• Re: Auto-Vacuum in 8.1 was ineffective for me. 8.2 may work better?
  • From: Mark Stosberg
• Re: General advice on user functions
  • From: Albert Cervera Areny
• Re: General advice on user functions
  • From: Merlin Moncure
• Re: Postgres performance Linux vs FreeBSD
  • From: Dimitri Fontaine
• Re: How to avoid vacuuming a huge logging table
  • From: Greg Sabino Mullane
• Re: Auto-Vacuum in 8.1 was ineffective for me. 8.2 may work better?
  • From: Alvaro Herrera
• Auto-Vacuum in 8.1 was ineffective for me. 8.2 may work better?
  • From: Mark Stosberg
• General advice on user functions
  • From: Dan Harris
• How to avoid vacuuming a huge logging table
  • From: Mark Stosberg
• Re: How to debug performance problems
  • From: Mark Stosberg
• Re: How to debug performance problems
  • From: Ray Stell
• Re: How to debug performance problems
  • From: Craig A. James
• Re: How to debug performance problems
  • From: Ray Stell
• Re: Postgres performance Linux vs FreeBSD
  • From: Bill Moran
• Re: Postgres performance Linux vs FreeBSD
  • From: Merlin Moncure
• Postgres performance Linux vs FreeBSD
  • From: Jacek Zaręba
• Re: slow subselects
  • From: Marko Niinimaki
• Re: SELECT performance problem
  • From: Dave Dutcher
• Re: SELECT performance problem
  • From: Jeff Frost
• SELECT performance problem
  • From: Glenn Sullivan
• Re: Query Optimization
  • From: Jim C. Nasby
• Re: slow subselects
  • From: Tom Lane
• Re: slow subselects
  • From: ismo . tuononen
• slow subselects
  • From: Marko Niinimaki
• Re: Query Optimization
  • From: Tom Lane
• Re: How to debug performance problems
  • From: Scott Marlowe
• Re: How to debug performance problems
  • From: Jeff Davis
• Re: How to debug performance problems
  • From: Craig A. James
• Query Optimization
  • From: Reinhard Vicinus
• How to debug performance problems
  • From: Andreas Tille
• Re: Not Picking Index
  • From: Tom Lane
• Re: reindex vs 'analyze'
  • From: Mark Stosberg
• Re: Not Picking Index
  • From: George Pavlov
• Re: Not Picking Index
  • From: Steinar H. Gunderson
• Re: Proximity query with GIST and row estimation
  • From: Guillaume Smet
• Re: Not Picking Index
  • From: Brad Nicholson
• Fwd: Not Picking Index
  • From: Mike Gargano
• Re: Not Picking Index
  • From: Tom Lane
• Re: Not Picking Index
  • From: Alvaro Herrera
• Re: Not Picking Index
  • From: Gauri Kanekar
• Re: Not Picking Index
  • From: Michael Fuhr
• Not Picking Index
  • From: Gauri Kanekar
• Re: Benchmarking PGSQL?
  • From: Krishna Kumar
• Re: Question about Bitmap Heap Scan/BitmapAnd
  • From: Guillaume Smet
• Re: Question about Bitmap Heap Scan/BitmapAnd
  • From: Guillaume Smet
• strange issue for certain queries
  • From: Mike Gargano
• Re: Slow query with 'or' clause
  • From: philippe
• Re: Question about Bitmap Heap Scan/BitmapAnd
  • From: Tom Lane
• Re: Question about Bitmap Heap Scan/BitmapAnd
  • From: Alvaro Herrera
• Re: Proximity query with GIST and row estimation
  • From: Guillaume Smet
• Re: Question about Bitmap Heap Scan/BitmapAnd
  • From: Guillaume Smet
• Re: Slow query with 'or' clause
  • From: Richard Huxton
• Slow query with 'or' clause
  • From: philippe
• Re: Problem with joining queries.
  • From: Konstantinos Krikellas
• Re: Problem with joining queries.
  • From: Richard Huxton
• Re: Benchmarking PGSQL?
  • From: Merlin Moncure
• Problem with joining queries.
  • From: Konstantinos Krikellas
• Re: An unwanted seqscan
  • From: Brian Herlihy
• Re: Benchmarking PGSQL?
  • From: Josh Berkus
• Re: Proximity query with GIST and row estimation
  • From: Paul Ramsey
• Re: How long should it take to insert 200,000 records?
  • From: Lou O'Quin
• Re: JOIN to a VIEW makes a real slow query
  • From: Chuck D.
• Re: reindex vs 'analyze'
  • From: Mark Stosberg
• Re: quad or dual core Intel CPUs
  • From: Claus Guttesen
• Re: Benchmarking PGSQL?
  • From: Luke Lonergan
• Re: Proximity query with GIST and row estimation
  • From: Guillaume Smet
• Re: reindex vs 'analyze' (was: Re: cube operations slower than geo_distance() on production server)
  • From: Tom Lane
• Re: quad or dual core Intel CPUs
  • From: Kenji Morishige
• reindex vs 'analyze' (was: Re: cube operations slower than geo_distance() on production server)
  • From: Mark Stosberg
• Re: Benchmarking PGSQL?
  • From: Merlin Moncure
• Re: Benchmarking PGSQL?
  • From: Luke Lonergan
• Re: cube operations slower than geo_distance() on production server
  • From: Merlin Moncure
• Re: Benchmarking PGSQL?
  • From: Shoaib Mir
• Benchmarking PGSQL?
  • From: Krishna Kumar
• Re: quad or dual core Intel CPUs
  • From: Claus Guttesen
• Re: An unwanted seqscan
  • From: Tom Lane