Postgres Performance Date Index

• Thread Index

• Re: update == delete + insert?
  • From: Merlin Moncure
• Re: Postmaster using only 4-5% CPU
  • From: Markus Bertheau
• Re: Perfomance test figures
  • From: Merlin Moncure
• Re: planner with index scan cost way off actual cost, advices to tweak cost constants?
  • From: Guillaume Cottenceau
• Re: planner with index scan cost way off actual cost,
  • From: Guillaume Cottenceau
• Postmaster using only 4-5% CPU
  • From: Edoardo Serra
• Re: Migration study, step 1: bulk write performance
  • From: Michael Stone
• Re: Migration study, step 1: bulk write performance
  • From: Jim C. Nasby
• Re: Best OS & Configuration for Dual Xeon w/4GB & Adaptec
  • From: Jim C. Nasby
• Re: Migration study, step 1: bulk write performance
  • From: Steinar H. Gunderson
• Re: Best OS & Configuration for Dual Xeon w/4GB & Adaptec
  • From: Alex Hayward
• WAL logging of SELECT ... INTO command
  • From: Jim C. Nasby
• Re: Migration study, step 1: bulk write performance
  • From: Jim C. Nasby
• Re: Migration study, step 1: bulk write performance
  • From: Steinar H. Gunderson
• Re: Migration study, step 1: bulk write performance
  • From: Jim C. Nasby
• Re: Migration study, step 1: bulk write performance
  • From: Csaba Nagy
• Re: planner with index scan cost way off actual cost, advices to tweak cost constants?
  • From: Jim C. Nasby
• Re: Migration study, step 1: bulk write performance
  • From: Steinar H. Gunderson
• Re: Migration study, step 1: bulk write performance
  • From: Csaba Nagy
• Re: planner with index scan cost way off actual cost,
  • From: Jim C. Nasby
• Re: Best OS & Configuration for Dual Xeon w/4GB &
  • From: Jim C. Nasby
• Re: Best OS & Configuration for Dual Xeon w/4GB & Adaptec
  • From: Jim C. Nasby
• Re: Perfomance test figures
  • From: Jim C. Nasby
• Re: Auto performance tuning?
  • From: Jim C. Nasby
• Re: Migration study, step 1: bulk write performance
  • From: Jim C. Nasby
• Re: update == delete + insert?
  • From: Jim C. Nasby
• Re: Best OS & Configuration for Dual Xeon w/4GB & Adaptec
  • From: Mark Kirkwood
• Re: Query Feromance
  • From: Thomas Pundt
• Re: planner with index scan cost way off actual cost,
  • From: Mark Kirkwood
• Re: Best OS & Configuration for Dual Xeon w/4GB & Adaptec RAID 2200S
  • From: Jim C. Nasby
• Re: Best OS & Configuration for Dual Xeon w/4GB &
  • From: Jim C. Nasby
• Re: planner with index scan cost way off actual cost, advices to tweak cost constants?
  • From: Guillaume Cottenceau
• Re: Best OS & Configuration for Dual Xeon w/4GB &
  • From: Jim C. Nasby
• Re: data doesnt get saved in the database / idle in transaction
  • From: Jim C. Nasby
• Re: partial indexes and inference
  • From: Jim C. Nasby
• Re: partitioning
  • From: Jim C. Nasby
• Re: planner with index scan cost way off actual cost, advices to tweak cost constants?
  • From: Jim C. Nasby
• Re: Query Feromance
  • From: Marco Furetto
• Re: planner with index scan cost way off actual cost, advices to tweak cost constants?
  • From: Jim C. Nasby
• Re: Query Feromance
  • From: Thomas Pundt
• Re: Query Feromance
  • From: Marco Furetto
• Perfomance test figures
  • From: Amit Soni
• Re: Best OS & Configuration for Dual Xeon w/4GB &
  • From: Mark Kirkwood
• Re: Best OS & Configuration for Dual Xeon w/4GB &
  • From: Mark Kirkwood
• Re: update == delete + insert?
  • From: Jaime Casanova
• Re: Migration study, step 1: bulk write performance optimization
  • From: Tom Lane
• Re: Best OS & Configuration for Dual Xeon w/4GB & Adaptec
  • From: PFC
• Re: update == delete + insert?
  • From: Tom Lane
• Re: Best OS & Configuration for Dual Xeon w/4GB & Adaptec
  • From: Miguel
• Re: Best OS & Configuration for Dual Xeon w/4GB & Adaptec RAID 2200S
  • From: Vivek Khera
• Re: Best OS & Configuration for Dual Xeon w/4GB & Adaptec
  • From: Miguel
• Re: update == delete + insert?
  • From: Jim Buttafuoco
• update == delete + insert?
  • From: Craig A. James
• Re: Best OS & Configuration for Dual Xeon w/4GB & Adaptec RAID 2200S
  • From: Vivek Khera
• Re: 1 TB of memory
  • From: Vivek Khera
• Re: Best OS & Configuration for Dual Xeon w/4GB &
  • From: Miguel
• Re: Best OS & Configuration for Dual Xeon w/4GB &
  • From: Luke Lonergan
• Re: Best OS & Configuration for Dual Xeon w/4GB & Adaptec
  • From: Miguel
• Re: Best OS & Configuration for Dual Xeon w/4GB &
  • From: Luke Lonergan
• Re: Best OS & Configuration for Dual Xeon w/4GB & Adaptec
  • From: Miguel
• Re: Best OS & Configuration for Dual Xeon w/4GB &
  • From: Luke Lonergan
• Re: Best OS & Configuration for Dual Xeon w/4GB & Adaptec
  • From: Miguel
• Re: Best OS & Configuration for Dual Xeon w/4GB &
  • From: Alex Hayward
• Re: 1 TB of memory
  • From: Merlin Moncure
• Re: Best OS & Configuration for Dual Xeon w/4GB & Adaptec RAID 2200S
  • From: Vivek Khera
• Auto performance tuning?
  • From: Orion Henry
• Re: 1 TB of memory
  • From: Vivek Khera
• Re: 1 TB of memory
  • From: Vivek Khera
• Re: Migration study, step 1: bulk write performance optimization
  • From: Dave Cramer
• Re: Query Feromance
  • From: Reimer
• Re: Migration study, step 1: bulk write performance optimization
  • From: PFC
• Re: Best OS & Configuration for Dual Xeon w/4GB &
  • From: Scott Marlowe
• Re: Migration study, step 1: bulk write performance
  • From: Csaba Nagy
• Re: Migration study, step 1: bulk write performance optimization
  • From: Craig A. James
• Query Feromance
  • From: Marco Furetto
• Migration study, step 1: bulk write performance optimization
  • From: Mikael Carneholm
• Re: Best OS & Configuration for Dual Xeon w/4GB &
  • From: Jim C. Nasby
• Re: data doesnt get saved in the database / idle in transaction
  • From: Qingqing Zhou
• data doesnt get saved in the database / idle in transaction
  • From: Ksenia Marasanova
• Re: planner with index scan cost way off actual cost, advices to tweak cost constants?
  • From: Guillaume Cottenceau
• Re: planner with index scan cost way off actual cost, advices to tweak cost constants?
  • From: Guillaume Cottenceau
• partial indexes and inference
  • From: Tim Allen
• Re: Best OS & Configuration for Dual Xeon w/4GB &
  • From: Dave Page
• Re: database model tshirt sizes
  • From: NbForYou
• Re: Best OS & Configuration for Dual Xeon w/4GB &
  • From: Luke Lonergan
• Re: n00b autovacuum question
  • From: Antoine
• Re: n00b autovacuum question
  • From: Andreas Pflug
• Re: database model tshirt sizes
  • From: me
• Re: database model tshirt sizes
  • From: Patrick Hatcher
• partitioning
  • From: Antoine
• Re: n00b autovacuum question
  • From: Antoine
• Re: Help optimizing a slow index scan
  • From: Oleg Bartunov
• Re: planner with index scan cost way off actual cost,
  • From: Mark Kirkwood
• Re: n00b autovacuum question
  • From: Andreas Pflug
• Re: n00b autovacuum question
  • From: Matthew T. O'Connor
• database model tshirt sizes
  • From: NbForYou
• Re: Help optimizing a slow index scan
  • From: Bruno Wolff III
• n00b autovacuum question
  • From: Antoine
• Re: planner with index scan cost way off actual cost, advices to tweak cost constants?
  • From: Guillaume Smet
• Re: Help optimizing a slow index scan
  • From: Oleg Bartunov
• Re: Help optimizing a slow index scan
  • From: Michael Fuhr
• Re: Help optimizing a slow index scan
  • From: Tom Lane
• Re: Best OS & Configuration for Dual Xeon w/4GB & Adaptec RAID 2200S
  • From: Kenji Morishige
• Re: Best OS & Configuration for Dual Xeon w/4GB &
  • From: Mark Kirkwood
• Re: Best OS & Configuration for Dual Xeon w/4GB & Adaptec RAID 2200S
  • From: Claus Guttesen
• Re: Best OS & Configuration for Dual Xeon w/4GB &
  • From: Scott Marlowe
• Re: Best OS & Configuration for Dual Xeon w/4GB & Adaptec RAID 2200S
  • From: Tom Lane
• Re: Best OS & Configuration for Dual Xeon w/4GB & Adaptec RAID 2200S
  • From: Claus Guttesen
• Re: Best OS & Configuration for Dual Xeon w/4GB &
  • From: Scott Marlowe
• Best OS & Configuration for Dual Xeon w/4GB & Adaptec RAID 2200S
  • From: Kenji Morishige
• Re: 1 TB of memory
  • From: Scott Marlowe
• Re: Help optimizing a slow index scan
  • From: Merlin Moncure
• Re: 1 TB of memory
  • From: Merlin Moncure
• Re: Help optimizing a slow index scan
  • From: Dan Harris
• Re: 1 TB of memory
  • From: Luke Lonergan
• Re: Help optimizing a slow index scan
  • From: Evgeny Gridasov
• Re: Background writer configuration
  • From: Evgeny Gridasov
• Re: Help optimizing a slow index scan
  • From: Merlin Moncure
• Re: Background writer configuration
  • From: 11
• Re: Help optimizing a slow index scan
  • From: Bruno Wolff III
• Re: 1 TB of memory
  • From: Jim C. Nasby
• Re: Background writer configuration
  • From: Steinar H. Gunderson
• Re: Background writer configuration
  • From: Steve Atkins
• Re: Help optimizing a slow index scan
  • From: Merlin Moncure
• Re: Help optimizing a slow index scan
  • From: Dan Harris
• Re: Help optimizing a slow index scan
  • From: Dan Harris
• Re: Background writer configuration
  • From: Kevin Grittner
• Re: 1 TB of memory
  • From: Merlin Moncure
• Re: Background writer configuration
  • From: PFC
• Re: Background writer configuration
  • From: Evgeny Gridasov
• Re: 1 TB of memory
  • From: Merlin Moncure
• Re: 1 TB of memory
  • From: Alex Stapleton
• Re: 1 TB of memory
  • From: Rodrigo Madera
• Re: Background writer configuration
  • From: PFC
• Re: 1 TB of memory
  • From: Michael Stone
• Re: 1 TB of memory
  • From: Luke Lonergan
• Re: Background writer configuration
  • From: Evgeny Gridasov
• planner with index scan cost way off actual cost, advices to tweak cost constants?
  • From: Guillaume Cottenceau
• Re: Indexes with descending date columns
  • From: andrew
• Re: 1 TB of memory
  • From: Josh Berkus
• Re: 1 TB of memory
  • From: Luke Lonergan
• Re: 1 TB of memory
  • From: Luke Lonergan
• Re: Background writer configuration
  • From: Kevin Grittner
• Re: Help optimizing a slow index scan
  • From: Dan Harris
• Help optimizing a slow index scan
  • From: Dan Harris
• Re: 1 TB of memory
  • From: Matthew Nuzum
• Re: 1 TB of memory
  • From: Ron Peacetree
• Indexes with descending date columns
  • From: Theo Kramer
• Re: BETWEEN optimizer problems with single-value
  • From: Simon Riggs
• Re: BETWEEN optimizer problems with single-value
  • From: Tom Lane
• Re: BETWEEN optimizer problems with single-value
  • From: Simon Riggs
• Re: BETWEEN optimizer problems with single-value
  • From: Alvaro Herrera
• Re: BETWEEN optimizer problems with single-value
  • From: Simon Riggs
• Re: 1 TB of memory
  • From: Joshua D. Drake
• 1 TB of memory
  • From: Jim Nasby
• Re: Background writer configuration
  • From: Evgeny Gridasov
• Re: PostgreSQL and Xeon MP
  • From: Guillaume Smet
• Re: PostgreSQL and Xeon MP
  • From: Sven Geisler
• Re: PostgreSQL and Xeon MP
  • From: Tom Lane
• Re: PostgreSQL and Xeon MP
  • From: Guillaume Smet
• Re: PostgreSQL and Xeon MP
  • From: Guillaume Smet
• Re: BETWEEN optimizer problems with single-value
  • From: Tom Lane
• Re: PostgreSQL and Xeon MP
  • From: Sven Geisler
• Re: PostgreSQL and Xeon MP
  • From: Tom Lane
• Re: PostgreSQL and Xeon MP
  • From: Kenneth Marshall
• Re: PostgreSQL and Xeon MP
  • From: Guillaume Smet
• Re: PostgreSQL and Xeon MP
  • From: Guillaume Smet
• Re: PostgreSQL and Xeon MP
  • From: Guillaume Smet
• Re: PostgreSQL and Xeon MP
  • From: Richard Huxton
• Re: PostgreSQL and Xeon MP
  • From: Sven Geisler
• Re: PostgreSQL and Xeon MP
  • From: Guillaume Smet
• Re: BETWEEN optimizer problems with single-value
  • From: Simon Riggs
• Re: PostgreSQL and Xeon MP
  • From: Richard Huxton
• PostgreSQL and Xeon MP
  • From: Guillaume Smet
• Re: BETWEEN optimizer problems with single-value
  • From: Tom Lane
• Re: Slow SELECTS after large update cycle
  • From: Jan de Visser
• Re: BETWEEN optimizer problems with single-value
  • From: Simon Riggs
• Re: BETWEEN optimizer problems with single-value
  • From: Simon Riggs
• Re: [HACKERS] BETWEEN optimizer problems with single-value
  • From: Kevin Grittner
• Re: Slow SELECTS after large update cycle
  • From: Simon Riggs
• Re: Slow SELECTS after large update cycle
  • From: Chris
• Re: [HACKERS] BETWEEN optimizer problems with single-value range
  • From: Simon Riggs
• Re: BETWEEN optimizer problems with single-value range
  • From: Merlin Moncure
• Re: BETWEEN optimizer problems with single-value range
  • From: Andreas Kretschmer
• Re: Background writer configuration
  • From: Kevin Grittner
• Re: BETWEEN optimizer problems with single-value
  • From: Kevin Grittner
• Re: Background writer configuration
  • From: Joshua D. Drake
• Background writer configuration
  • From: Kevin Grittner
• Slow SELECTS after large update cycle
  • From: Jan de Visser
• Re: BETWEEN optimizer problems with single-value range
  • From: Merlin Moncure
• Re: BETWEEN optimizer problems with single-value
  • From: Tom Lane
• Re: BETWEEN optimizer problems with single-value
  • From: Kevin Grittner
• Re: VACUUM FULL hangs
  • From: Marcin Mańk
• Re: BETWEEN optimizer problems with single-value range
  • From: Andreas Kretschmer
• BETWEEN optimizer problems with single-value range
  • From: Kevin Grittner
• Re: VACUUM FULL hangs
  • From: Richard Huxton
• VACUUM FULL hangs
  • From: Marcin Mańk
• Re: x206-x225
  • From: Richard Huxton
• Re: Vacuum template databases, Urgent: Production probl
  • From: Vivek Khera
• Re: x206-x225
  • From: Jim C. Nasby
• Re: x206-x225
  • From: Richard Huxton
• Re: Vacuum template databases, Urgent: Production probl
  • From: Jim C. Nasby
• Re: Vacuum template databases, Urgent: Production probl
  • From: mcelroy, tim
• Re: Vacuum template databases, Urgent: Production probl
  • From: Jim C. Nasby
• Re: Vacuum template databases, Urgent: Production problem
  • From: Jim C. Nasby
• Re: firebird X postgresql 8.1.2 windows, performance comparison
  • From: Jim C. Nasby
• Re: x206-x225
  • From: Jim C. Nasby
• Re: firebird X postgresql 8.1.2 windows, performance comparison
  • From: Jim C. Nasby
• Re: Process Time X200
  • From: Jim C. Nasby
• Re: firebird X postgresql 8.1.2 windows, performance comparison
  • From: Merlin Moncure
• firebird X postgresql 8.1.2 windows, performance comparison
  • From: andremachado
• Re: Vacuum template databases, Urgent: Production probl
  • From: mcelroy, tim
• Re: Vacuum template databases, Urgent: Production problem
  • From: Tom Lane
• Vacuum template databases, Urgent: Production problem
  • From: Pallav Kalva
• Re: firebird X postgresql 8.1.2 windows, performance comparison
  • From: Merlin Moncure
• Re: PG Statistics
  • From: mcelroy, tim
• Re: PG Statistics
  • From: mcelroy, tim
• firebird X postgresql 8.1.2 windows, performance comparison
  • From: andremachado
• Re: import performance
  • From: Chris
• Re: import performance
  • From: David Lang
• Re: import performance
  • From: Chris
• Re: import performance
  • From: Frank Wiles
• Re: import performance
  • From: Tom Lane
• Re: import performance
  • From: Chris
• Re: import performance
  • From: Frank Wiles
• Re: import performance
  • From: Chris
• Re: import performance
  • From: Gavin Sherry
• Re: import performance
  • From: Dave Dutcher
• Re: PG Statistics
  • From: Steve Poe
• Re: import performance
  • From: Gavin Sherry
• import performance
  • From: Chris
• Re: PG Statistics
  • From: Michael Fuhr
• PG Statistics
  • From: mcelroy, tim
• Re: firebird X postgresql 8.1.2 windows, performance
  • From: Scott Marlowe
• Re: No vacuum for insert-only database?
  • From: Josh Berkus
• Re: firebird X postgresql 8.1.2 windows, performance comparison
  • From: Josh Berkus
• Re: No vacuum for insert-only database?
  • From: Bruno Wolff III
• firebird X postgresql 8.1.2 windows, performance comparison
  • From: andremachado
• Re: No vacuum for insert-only database?
  • From: Alvaro Herrera
• Re: No vacuum for insert-only database?
  • From: Craig A. James
• Re: No vacuum for insert-only database?
  • From: Alvaro Herrera
• No vacuum for insert-only database?
  • From: Craig A. James
• unsubscribe
  • From: Nick Howden
• Re: Query time
  • From: PFC
• Re: Query time
  • From: Ruben Rubio Rey
• Re: help needed asap....
  • From: Bruno Wolff III
• Re: help needed asap....
  • From: Matthew Nuzum
• help needed asap....
  • From: Phadnis
• Re: Postgres and Ingres R3 / SAN
  • From: Josh Berkus
• Re: x206-x225
  • From: David Lang
• Re: x206-x225
  • From: Joost Kraaijeveld
• Re: x206-x225
  • From: Tom Lane
• Re: x206-x225
  • From: Joost Kraaijeveld
• Re: x206-x225
  • From: PFC
• Re: x206-x225
  • From: Joost Kraaijeveld
• Re: x206-x225
  • From: David Lang
• Re: x206-x225
  • From: Joost Kraaijeveld
• Re: firebird X postgresql 8.1.2 windows, performance comparison
  • From: Chris Travers
• firebird X postgresql 8.1.2 windows, performance comparison
  • From: Andre Felipe Machado
• Re: Trouble managing planner for timestamptz columns
  • From: Tom Lane
• Re: Trouble managing planner for timestamptz columns
  • From: Marc Morin
• Re: Hanging queries on dual CPU windows
  • From: Jan de Visser
• Re: Hanging queries on dual CPU windows
  • From: Jan de Visser
• Re: one-field index vs. multi-field index planner
  • From: Tom Lane
• Re: Hanging queries on dual CPU windows
  • From: Magnus Hagander
• Re: Trouble managing planner for timestamptz columns
  • From: Tom Lane
• Trouble managing planner for timestamptz columns
  • From: Marc Morin
• Re: one-field index vs. multi-field index planner
  • From: Evgeny Gridasov
• Re: one-field index vs. multi-field index planner estimates
  • From: Tom Lane
• Re: Process Time X200
  • From: Scott Marlowe
• one-field index vs. multi-field index planner estimates
  • From: Evgeny Gridasov
• Re: Hanging queries on dual CPU windows
  • From: Jan de Visser
• Re: Process Time X200
  • From: Matthew Nuzum
• Re: Query time
  • From: Jim C. Nasby
• Re: Using materialized views for commonly-queried subsets
  • From: Jim C. Nasby
• Re: pg_reset_stats + cache I/O %
  • From: Jim C. Nasby
• Re: Hanging queries on dual CPU windows
  • From: Magnus Hagander
• Re: Hanging queries on dual CPU windows
  • From: Jan de Visser
• Re: Hanging queries on dual CPU windows
  • From: Jan de Visser
• Re: Hanging queries on dual CPU windows
  • From: Hakan Kocaman
• Re: x206-x225
  • From: Daniel Blaisdell
• Re: Query time
  • From: Richard Huxton
• Re: x206-x225
  • From: Richard Huxton
• Re: Hanging queries on dual CPU windows
  • From: Jan de Visser
• Re: Query time
  • From: Ruben Rubio Rey
• Re: Process Time X200
  • From: PFC
• Re: Query time
  • From: Michael Fuhr
• Re: Process Time X200
  • From: NbForYou
• Re: Query time
  • From: Ruben Rubio Rey
• Re: Process Time X200
  • From: Richard Huxton
• Query time
  • From: Ruben Rubio Rey
• FW: x206-x226
  • From: H.J. Sanders
• x206-x225
  • From: H.J. Sanders
• Re: Process Time X200
  • From: Ragnar
• Re: Process Time X200
  • From: Guido Neitzer
• Re: Hanging queries on dual CPU windows
  • From: Magnus Hagander
• Re: Process Time X200
  • From: NbForYou
• Re: Process Time X200
  • From: Michael Fuhr
• Process Time X200
  • From: NbForYou
• Using materialized views for commonly-queried subsets
  • From: Casey Allen Shobe
• Re: firebird X postgresql 8.1.2 windows, performance comparison
  • From: David Brown
• Re: Hanging queries on dual CPU windows
  • From: Jan de Visser
• Re: pgCluster and postgres 8.1
  • From: Chris
• Re: Hanging queries on dual CPU windows
  • From: Magnus Hagander
• Re: Hanging queries on dual CPU windows
  • From: Jan de Visser
• Re: Hanging queries on dual CPU windows
  • From: Tom Lane
• Re: Hanging queries on dual CPU windows
  • From: Jan de Visser
• Re: pg_reset_stats + cache I/O %
  • From: mcelroy, tim
• Re: firebird X postgresql 8.1.2 windows, performance comparison
  • From: PFC
• Re: firebird X postgresql 8.1.2 windows, performance comparison
  • From: Carlos Henrique Reimer
• pgCluster and postgres 8.1
  • From: Javier Somoza
• Re: pg_reset_stats + cache I/O %
  • From: Jim C. Nasby
• embedded postgres and threading
  • From: Gorshkov
• Re: Postgres and Ingres R3 / SAN
  • From: Jim Nasby
• Re: Is good idea an array of 365 elements in a cell of a table, in order to perform searchs?
  • From: Jim C. Nasby
• Re: pg_reset_stats + cache I/O %
  • From: mcelroy, tim
• Re: pg_reset_stats + cache I/O %
  • From: Jim C. Nasby
• Re: Bad row estimates
  • From: Greg Stark
• Re: Bad row estimates
  • From: Alex Adriaanse
• Is good idea an array of 365 elements in a cell of a table, in order to perform searchs?
  • From: Ruben Rubio Rey
• Re: pg_reset_stats + cache I/O %
  • From: mcelroy, tim
• Re: Postgres on VPS - how much is enough?
  • From: Matthew Nuzum
• Re: firebird X postgresql 8.1.2 windows, performance comparison
  • From: Andre Felipe Machado
• Re: Can anyone explain this pgbench results?
  • From: Jim C. Nasby
• Re: Can anyone explain this pgbench results?
  • From: Joost Kraaijeveld
• Re: Postgres on VPS - how much is enough?
  • From: Dave Page
• Re: Can anyone explain this pgbench results?
  • From: Jim C. Nasby
• Re: firebird X postgresql 8.1.2 windows, performance
  • From: Tom Lane
• Re: Can anyone explain this pgbench results?
  • From: Joost Kraaijeveld
• Re: pg_reset_stats + cache I/O %
  • From: Tom Lane
• Re: Postgres and Ingres R3 / SAN
  • From: Jim C. Nasby
• Re: Postgres and Ingres R3 / SAN
  • From: Mark Lewis
• Re: Can anyone explain this pgbench results?
  • From: Jim C. Nasby
• pg_reset_stats + cache I/O %
  • From: mcelroy, tim
• Re: Postgres and Ingres R3 / SAN
  • From: Jim C. Nasby
• Re: Postgres on VPS - how much is enough?
  • From: Jim C. Nasby
• Re: t1000/t2000 sun-servers
  • From: Jim C. Nasby
• Re: Planner enhancement suggestion.
  • From: Jim C. Nasby
• Re: Planner enhancement suggestion.
  • From: PFC
• Re: firebird X postgresql 8.1.2 windows, performance
  • From: Alvaro Herrera
• Re: firebird X postgresql 8.1.2 windows, performance
  • From: Scott Marlowe
• Re: firebird X postgresql 8.1.2 windows, performance
  • From: Alvaro Herrera
• Re: firebird X postgresql 8.1.2 windows, performance
  • From: Scott Marlowe
• Re: firebird X postgresql 8.1.2 windows, performance comparison
  • From: Carlos Henrique Reimer
• Re: firebird X postgresql 8.1.2 windows, performance comparison
  • From: Joshua D. Drake
• firebird X postgresql 8.1.2 windows, performance comparison
  • From: andremachado
• Re: Help understanding indexes, explain, and optimizing
  • From: Tom Lane
• Re: Help understanding indexes, explain, and optimizing
  • From: Dave Dutcher
• Re: Can anyone explain this pgbench results?
  • From: Joost Kraaijeveld
• Re: Can anyone explain this pgbench results?
  • From: Joost Kraaijeveld
• Re: Sequencial scan instead of using index
  • From: Mark Kirkwood
• Re: Can anyone explain this pgbench results?
  • From: Michael Fuhr
• Re: Help understanding indexes, explain, and optimizing
  • From: i.v.r.
• Re: Help understanding indexes, explain, and optimizing
  • From: Chris
• Re: Planner enhancement suggestion.
  • From: Jim C. Nasby
• Help understanding indexes, explain, and optimizing a query
  • From: i.v.r.
• Re: t1000/t2000 sun-servers
  • From: Jignesh K. Shah
• Re: t1000/t2000 sun-servers
  • From: Guido Neitzer
• Re: Sequencial scan instead of using index
  • From: Ragnar
• Re: Can anyone explain this pgbench results?
  • From: Michael Fuhr
• Re: t1000/t2000 sun-servers
  • From: Jignesh K. Shah
• Postgres and Ingres R3 / SAN
  • From: Jeremy Haile
• Re: Postgres on VPS - how much is enough?
  • From: Matthew Nuzum
• Sequencial scan instead of using index
  • From: Harry Hehl
• Re: Can anyone explain this pgbench results?
  • From: Joost Kraaijeveld
• Re: Can anyone explain this pgbench results?
  • From: Michael Fuhr
• Re: Postgres on VPS - how much is enough?
  • From: Marc G. Fournier
• Re: Postgres on VPS - how much is enough?
  • From: Nagita Karunaratne
• Can anyone explain this pgbench results?
  • From: Joost Kraaijeveld
• Re: Postgres on VPS - how much is enough?
  • From: Kevin
• Re: Postgres on VPS - how much is enough?
  • From: Matthew Nuzum
• Hanging queries and I/O exceptions
  • From: Jan de Visser
• Re: t1000/t2000 sun-servers
  • From: Neil Saunders
• Postgres on VPS - how much is enough?
  • From: Nagita Karunaratne
• t1000/t2000 sun-servers
  • From: Claus Guttesen
• Planner enhancement suggestion.
  • From: PFC
• Re: How to query and index for customer with lastname and city
  • From: Kevin Brown
• Re: Bad row estimates
  • From: Greg Stark
• Re: Bad row estimates
  • From: Tom Lane
• Re: Bad row estimates
  • From: Jim C. Nasby
• Re: How to query and index for customer with lastname and city
  • From: hubert depesz lubaczewski
• Re: How to query and index for customer with lastname
  • From: Joost Kraaijeveld
• Re: How to query and index for customer with lastname and city
  • From: hubert depesz lubaczewski
• How to query and index for customer with lastname and city
  • From: Joost Kraaijeveld
• Re: Bad row estimates
  • From: Greg Stark
• Re: Bad row estimates
  • From: Greg Stark
• Bad row estimates
  • From: Alex Adriaanse
• Re: Like 'name%' is not using index
  • From: Greg Stark
• Re: Like 'name%' is not using index
  • From: Jozsef Szalay
• Re: Like 'name%' is not using index
  • From: Mark Kirkwood
• Like 'name%' is not using index
  • From: Jozsef Szalay
• Re: [HACKERS] qsort again (was Re: Strange Create Index behaviour)
  • From: Bruce Momjian
• Re: Bad plan on a view
  • From: Jim C. Nasby
• Re: triggers, performance Was: Re: [GENERAL] rotate records
  • From: Jim C. Nasby
• Re: Looking for a tool to "*" pg tables as ERDs
  • From: Robert Treat
• Re: Bad plan on a view
  • From: PFC
• Re: [HACKERS] temporary indexes
  • From: Kevin Grittner
• Re: Bad plan on a view
  • From: Greg Stark
• Re: Bad plan on a view
  • From: PFC
• Re: Bad plan on a view
  • From: Tom Lane
• Bad plan on a view
  • From: PFC
• Re: wal sync method
  • From: PFC
• Re: nested query on last n rows of huge table
  • From: Michael Glaesemann
• Re: Large Table With Only a Few Rows
  • From: Bruno Wolff III
• Re: wal sync method
  • From: Tom Lane
• Re: wal sync method
  • From: PFC
• Re: [HACKERS] temporary indexes
  • From: Kevin Grittner
• Re: fsync and battery-backed caches
  • From: Jim C. Nasby
• Re: [HACKERS] temporary indexes
  • From: Jim C. Nasby
• Re: [HACKERS] temporary indexes
  • From: Kevin Grittner
• Re: [HACKERS] temporary indexes
  • From: Steinar H. Gunderson
• Re: [HACKERS] temporary indexes
  • From: Tom Lane
• Re: [HACKERS] temporary indexes
  • From: Kevin Grittner
• Re: fsync and battery-backed caches
  • From: Javier Somoza
• Re: [HACKERS] temporary indexes
  • From: Kevin Grittner
• Re: fsync and battery-backed caches
  • From: Jim C. Nasby
• Re: [HACKERS] temporary indexes
  • From: Tom Lane
• Re: temporary indexes
  • From: Tom Lane
• Re: [HACKERS] temporary indexes
  • From: Jim C. Nasby
• temporary indexes
  • From: Kevin Grittner
• Re: Different disks for xlogs and data
  • From: Ron
• Re: vacuum, analyze and reindex
  • From: Christopher Browne
• vacuum, analyze and reindex
  • From: Javier Somoza
• Different disks for xlogs and data
  • From: Javier Somoza
• Re: fsync and battery-backed caches
  • From: Javier Somoza
• Re: triggers, performance Was: Re: [GENERAL] rotate records
  • From: Jeevanandam, Kathirvel (IE10)
• Re: rotate records
  • From: Bruno Wolff III
• Re: wal sync method
  • From: Bruce Momjian
• Re: fsync and battery-backed caches
  • From: Bruce Momjian
• Re: fsync and battery-backed caches
  • From: Jim C. Nasby
• Re: Large Table With Only a Few Rows
  • From: Peter Childs
• Re: The trigger can be specified to fire on time condition?
  • From: Chris Browne
• Re: Large Table With Only a Few Rows
  • From: Chris Browne
• Re: The trigger can be specified to fire on time condition?
  • From: Alvaro Herrera
• The trigger can be specified to fire on time condition?
  • From: Jamal Ghaffour
• Re: neverending vacuum
  • From: Csaba Nagy
• Large Table With Only a Few Rows
  • From: Nik
• Re: neverending vacuum
  • From: Alvaro Herrera
• neverending vacuum
  • From: Csaba Nagy
• Re: Setting the shared buffers
  • From: Claus Guttesen
• Setting the shared buffers
  • From: Javier Somoza
• Re: wal sync method
  • From: Javier Somoza
• wal sync method
  • From: Evgeny Gridasov
• Re: fsync and battery-backed caches
  • From: Tino Wildenhain
• fsync and battery-backed caches
  • From: Javier Somoza
• Re: Schema vs Independant Databases, ACLS,Overhead,pg_hba.conf
  • From: Alvaro Herrera
• Re: Reliability recommendations
  • From: Luke Lonergan
• Re: Reliability recommendations
  • From: Ron
• Re: Reliability recommendations
  • From: Ron
• Re: Reliability recommendations
  • From: Mark Kirkwood
• Re: Reliability recommendations
  • From: Luke Lonergan
• Re: Reliability recommendations
  • From: Mark Kirkwood
• Re: Reliability recommendations
  • From: Luke Lonergan
• Re:
  • From: Bruce Momjian
• Re: Reliability recommendations
  • From: Mark Kirkwood
• Re: Reliability recommendations
  • From: Dan Gorman
• Re: Reliability recommendations
  • From: Mark Kirkwood
• Re: Reliability recommendations
  • From: Philippe Marzin
• Re: Reliability recommendations
  • From: Luke Lonergan
• Re: Reliability recommendations
  • From: Scott Marlowe
• Re: Reliability recommendations
  • From: Craig A. James
• Re: Creating a correct and real benchmark
  • From: Marcos
• Schema vs Independant Databases, ACLS,Overhead,pg_hba.conf
  • From: Eric Lauzon
• Re: Reliability recommendations
  • From: Joshua D. Drake
• Re: Reliability recommendations
  • From: Scott Marlowe
• Re: Reliability recommendations
  • From: Vivek Khera
• Re: Reliability recommendations
  • From: Scott Marlowe
• Re: Reliability recommendations
  • From: Vivek Khera
• Re: Reliability recommendations
  • From: Luke Lonergan
• Re: Reliability recommendations
  • From: Luke Lonergan
• Re: Reliability recommendations
  • From: Craig A. James
• Re: Reliability recommendations
  • From: Bruce Momjian
• Re: nested query on last n rows of huge table
  • From: jcfischer
• nested query on last n rows of huge table
  • From: jcfischer
• Re: Really really slow query. What's a better way?
  • From: Brendan Duddridge
• Re: Really really slow query. What's a better way?
  • From: Christopher Kings-Lynne
• Really really slow query. What's a better way?
  • From: Brendan Duddridge
• Re: 0ut of Memory Error during Vacuum Analyze and
  • From: Tom Lane
• Re: 0ut of Memory Error during Vacuum Analyze and
  • From: Tomeh, Husam
• Re: Good News re count(*) in 8.1
  • From: Jim C. Nasby
• Re:
  • From: Jim C. Nasby
• Re: 0ut of Memory Error during Vacuum Analyze and
  • From: Tomeh, Husam
• Re: Good News re count(*) in 8.1
  • From: Kevin Grittner
• Re: Slow query
  • From: Tom Lane
• Re: Looking for a tool to "*" pg tables as ERDs
  • From: Vivek Khera
• Re: Looking for a tool to "*" pg tables as ERDs
  • From: Markus Schaber
• Looking for a tool to "*" pg tables as ERDs
  • From: Ron Peacetree
• how to interpret/improve bad row estimates
  • From: Robert Treat
• Re:
  • From: Vivek Khera
• Re: Created Index is not used
  • From: Kjeld Peters
• Re: Created Index is not used
  • From: Markus Schaber
• Re: Created Index is not used
  • From: Ragnar
• Re: LIKE query on indexes
  • From: Ibrahim Tekin
• Created Index is not used
  • From: Kjeld Peters
• Re: Joins and full index scans...mysql vs postgres?
  • From: Andreas Pflug
• Re: Good News re count(*) in 8.1
  • From: Greg Stark
• Re: Joins and full index scans...mysql vs postgres?
  • From: Christopher Kings-Lynne
• Re: Joins and full index scans...mysql vs postgres?
  • From: Chris
• Re: Joins and full index scans...mysql vs postgres?
  • From: PFC
• Re: Large Database Design Help
  • From: Orion
• Slow query
  • From: Jeremy Haile
• Re: Joins and full index scans...mysql vs postgres?
  • From: Scott Marlowe
• Re: Joins and full index scans...mysql vs postgres?
  • From: ryan groth
• Re: Joins and full index scans...mysql vs postgres?
  • From: Stephan Szabo
• Re: Joins and full index scans...mysql vs postgres?
  • From: ryan groth
• Re: Joins and full index scans...mysql vs postgres?
  • From: ryan groth
• Re: Joins and full index scans...mysql vs postgres?
  • From: Steinar H. Gunderson
• Re: Good News re count(*) in 8.1
  • From: Tom Lane
• Joins and full index scans...mysql vs postgres?
  • From: ryan groth
• Re: --pls reply ASAP
  • From: Theodore LoScalzo
• Re: Good News re count(*) in 8.1
  • From: Luke Lonergan
• Good News re count(*) in 8.1
  • From: Kevin Grittner
• Re:
  • From: Vivek Khera
• Re: LIKE query on indexes
  • From: Brendan Duddridge
• Re: Help with nested loop left join performance
  • From: Tom Lane
• Re: --pls reply ASAP
  • From: Richard Huxton
• Re:
  • From: Gourish Singbal
• Re:
  • From: Richard Huxton
• [no subject]
  • From: Chethana, Rao (IE10)
• Re: Help with nested loop left join performance
  • From: Richard Huxton
• Re: How to optimize a JOIN with BETWEEN?
  • From: Jim C. Nasby
• Re: LIKE query on indexes
  • From: Ibrahim Tekin
• Help with nested loop left join performance
  • From: George Woodring
• Re: LIKE query on indexes
  • From: Ibrahim Tekin
• Re: LIKE query on indexes
  • From: mark
• Re: LIKE query on indexes
  • From: Scott Marlowe
• Re: LIKE query on indexes
  • From: Alvaro Herrera
• Re: LIKE query on indexes
  • From: Scott Marlowe
• LIKE query on indexes
  • From: Ibrahim Tekin
• Re: Cost Issue - How do I force a Hash Join
  • From: Virag Saksena
• Re: Cost Issue - How do I force a Hash Join
  • From: Craig A. James
• Re: Cost Issue - How do I force a Hash Join
  • From: Tom Lane
• Cost Issue - How do I force a Hash Join
  • From: Virag Saksena
• Re: Creating a correct and real benchmark
  • From: Chris
• Re: Creating a correct and real benchmark
  • From: PFC
• Re: Force another plan.
  • From: Tom Lane
• Creating a correct and real benchmark
  • From: Marcos
• Re: Force another plan.
  • From: Fredrik Olsson
• Re: Avoiding cartesian product
  • From: Virag Saksena
• Re: Need pointers to "standard" pg database(s) for
  • From: Christopher Kings-Lynne
• How to optimize a JOIN with BETWEEN?
  • From: andrew
• Re: Need pointers to "standard" pg database(s) for testing
  • From: Christopher Kings-Lynne
• Re: Question about query planner
  • From: Tom Lane
• Re: Force another plan.
  • From: Tom Lane
• Question about query planner
  • From: Emil Briggs
• Re: Force another plan.
  • From: Fredrik Olsson
• Re: Force another plan.
  • From: Tom Lane
• Re: [HACKERS] qsort again (was Re: Strange Create
  • From: Ron
• Force another plan.
  • From: Fredrik Olsson
• Re: Index Choice Problem
  • From: Adam Alkins
• Re: Index Choice Problem
  • From: Adam Alkins
• Re: Index Choice Problem
  • From: Tom Lane
• Re: [HACKERS] qsort again (was Re: Strange Create
  • From: Gregory Maxwell
• Measuring Lock Performance
  • From: Lane Van Ingen
• Re: [HACKERS] qsort again (was Re: Strange Create Index
  • From: Tom Lane
• Re: [HACKERS] qsort again (was Re: Strange Create
  • From: Ragnar
• Re: [HACKERS] qsort again (was Re: Strange Create Index
  • From: Mark Lewis
• Re: [HACKERS] Need pointers to "standard" pg database(s) for testing
  • From: Michael Paesold
• Re: Need pointers to "standard" pg database(s) for
  • From: Scott Marlowe
• Need pointers to "standard" pg database(s) for testing
  • From: Ron
• Re: [HACKERS] qsort again (was Re: Strange Create
  • From: Ron
• Re: [HACKERS] qsort again (was Re: Strange Create Index
  • From: Martijn van Oosterhout
• Re: [HACKERS] qsort again (was Re: Strange Create Index
  • From: Scott Lamb
• Re: [HACKERS] qsort again (was Re: Strange Create
  • From: Martijn van Oosterhout
• Re: split partitioned table across several postgres servers
  • From: martial . bizel
• Re: split partitioned table across several postgres servers
  • From: Tom Lane
• Re: [HACKERS] qsort again (was Re: Strange Create
  • From: Ron
• Re: [HACKERS] qsort again (was Re: Strange Create
  • From: Ron
• Re: [HACKERS] qsort again (was Re: Strange Create
  • From: PFC
• Re: [HACKERS] qsort again (was Re: Strange Create
  • From: Markus Schaber
• Re: [HACKERS] qsort again (was Re: Strange Create Index
  • From: Markus Schaber
• Re: [HACKERS] qsort again (was Re: Strange Create
  • From: Ragnar
• split partitioned table across several postgres servers
  • From: martial . bizel
• Re: [HACKERS] qsort again (was Re: Strange Create
  • From: Ron
• Re: [HACKERS] qsort again (was Re: Strange Create Index
  • From: David Lang
• Re: [HACKERS] qsort again (was Re: Strange Create Index
  • From: Steinar H. Gunderson
• Re: [HACKERS] qsort again (was Re: Strange Create Index
  • From: Markus Schaber
• Re: [HACKERS] qsort again (was Re: Strange Create Index
  • From: Mark Lewis
• Re: [HACKERS] qsort again (was Re: Strange Create Index
  • From: PFC
• Re: [HACKERS] qsort again (was Re: Strange Create Index
  • From: Greg Stark
• Re: [HACKERS] qsort again (was Re: Strange Create Index
  • From: Martijn van Oosterhout
• Re: [HACKERS] qsort again (was Re: Strange Create Index
  • From: Markus Schaber
• Re: [HACKERS] qsort again (was Re: Strange Create Index
  • From: Mark Lewis
• Re: Why does not perform index combination
  • From: Adnan DURSUN
• Re: qsort again (was Re: Strange Create Index
  • From: Neil Conway
• Re: [HACKERS] qsort again (was Re: Strange Create
  • From: Ron
• Re: [HACKERS] qsort again (was Re: Strange Create Index
  • From: Dann Corbit
• Re: [HACKERS] qsort again (was Re: Strange Create
  • From: Scott Lamb
• Re: Why does not perform index combination
  • From: Tom Lane
• Re: [HACKERS] qsort again (was Re: Strange Create Index
  • From: Tom Lane
• Index Choice Problem
  • From: Adam Alkins
• Future of Table Partitioning
  • From: Patrick Carriere
• Why does not perform index combination
  • From: Adnan DURSUN
• Re: [HACKERS] qsort again (was Re: Strange Create
  • From: Martijn van Oosterhout
• Re: [HACKERS] qsort again (was Re: Strange Create
  • From: Ron
• Re: qsort again (was Re: Strange Create Index
  • From: Craig A. James
• Re: [HACKERS] qsort again (was Re: Strange Create
  • From: Tom Lane
• Re: [HACKERS] qsort again (was Re: Strange Create
  • From: Ron
• Re: [HACKERS] qsort again (was Re: Strange Create Index
  • From: Gary Doades
• Re: [HACKERS] qsort again (was Re: Strange Create Index
  • From: Martijn van Oosterhout
• Re: [HACKERS] qsort again (was Re: Strange Create Index behaviour)
  • From: Tom Lane
• Re: [HACKERS] qsort again (was Re: Strange Create Index
  • From: Jonah H. Harris
• Re: qsort again (was Re: Strange Create Index
  • From: Markus Schaber
• Re: [HACKERS] qsort again
  • From: Ron
• Re: Postgres slower than MS ACCESS
  • From: Peter Childs
• Re: qsort again (was Re: Strange Create Index
  • From: Ron
• Re: [HACKERS] qsort again
  • From: Sven Geisler
• Re: [HACKERS] qsort again
  • From: Martijn van Oosterhout
• Re: [HACKERS] qsort again
  • From: Florian Weimer
• Re: qsort again (was Re: Strange Create Index
  • From: Steinar H. Gunderson
• Re: [HACKERS] qsort again (was Re: Strange Create Index
  • From: Gary Doades
• Re: qsort again (was Re: Strange Create Index
  • From: Ron
• Re: [HACKERS] qsort again (was Re: Strange Create Index
  • From: Neil Conway
• Re: [HACKERS] qsort again (was Re: Strange Create Index
  • From: Simon Riggs
• Re: Strange Create Index behaviour
  • From: Simon Riggs
• Re: qsort again (was Re: Strange Create Index behaviour)
  • From: Christopher Kings-Lynne
• Re: [HACKERS] qsort again (was Re: Strange Create Index behaviour)
  • From: Dann Corbit
• Re: qsort again (was Re: Strange Create Index behaviour)
  • From: Tom Lane
• Re: [HACKERS] qsort again (was Re: Strange Create Index behaviour)
  • From: Tom Lane
• Re: qsort again (was Re: Strange Create Index
  • From: Ron
• Re: [HACKERS] qsort again (was Re: Strange Create Index behaviour)
  • From: Tom Lane
• Re: qsort again (was Re: Strange Create Index behaviour)
  • From: Tom Lane
• Re: qsort again (was Re: Strange Create Index behaviour)
  • From: Gary Doades
• Re: Strange Create Index behaviour
  • From: Simon Riggs
• qsort again (was Re: Strange Create Index behaviour)
  • From: Tom Lane
• Re: Strange Create Index behaviour
  • From: Gary Doades
• Re: Strange Create Index behaviour
  • From: Tom Lane
• Re: Reliability recommendations
  • From: Josh Rovero
• Re: Strange Create Index behaviour
  • From: Tom Lane
• Re: Postgres slower than MS ACCESS
  • From: Tom Lane
• Re: Strange Create Index behaviour
  • From: Gary Doades
• Re: Postgres slower than MS ACCESS
  • From: Jay Greenfield
• Re: Strange Create Index behaviour
  • From: Tom Lane
• Re: Strange Create Index behaviour
  • From: Simon Riggs
• Re: Strange Create Index behaviour
  • From: Gary Doades
• Re: Strange Create Index behaviour
  • From: Gary Doades
• Re: Reliability recommendations
  • From: Jeremy Haile
• Re: Strange Create Index behaviour
  • From: Tom Lane
• Strange Create Index behaviour
  • From: Gary Doades
• Re: Reliability recommendations
  • From: Ron
• Re: Reliability recommendations
  • From: Scott Marlowe
• Re: Reliability recommendations
  • From: Christopher Browne
• Re: Reliability recommendations
  • From: Greg Stark
• Re: Reliability recommendations
  • From: Joshua D. Drake
• Re: out of memory
  • From: Scott Marlowe
• Re: Reliability recommendations
  • From: Mark Lewis
• Re: Reliability recommendations
  • From: Craig A. James
• Re: out of memory
  • From: martial . bizel
• Re: out of memory
  • From: Scott Marlowe
• Re: out of memory
  • From: martial . bizel
• Reliability recommendations
  • From: Jeremy Haile
• Re: explain hashAggregate
  • From: martial . bizel
• out of memory
  • From: martial . bizel
• Stored proc and optimizer question
  • From: Antal Attila
• Re: copy and postgresql.conf
  • From: Tom Lane
• Re: copy and postgresql.conf
  • From: Jignesh K. Shah
• Re: copy and postgresql.conf
  • From: FERREIRA, William (VALTECH)
• Re: Postgres slower than MS ACCESS
  • From: Jeff Trout
• Re: copy and postgresql.conf
  • From: Jignesh K. Shah
• Re: copy and postgresql.conf
  • From: FERREIRA, William (VALTECH)
• Re: copy and postgresql.conf
  • From: Markus Schaber
• Stored proc and optimizer question
  • From: Antal Attila
• Re: copy and postgresql.conf
  • From: FERREIRA, William (VALTECH)
• Re: could not send data to client: Broken pipe
  • From: Richard Huxton
• Re: out of memory
  • From: martial . bizel
• could not send data to client: Broken pipe
  • From: Pradeep Parmar