Postgres Performance Date Index

• Thread Index

• Re: SELECT FOR UPDATE performance is bad
  • From: Mario Splivalo
• Re: SELECT FOR UPDATE performance is bad
  • From: Mario Splivalo
• Re: Multicolumn order by
  • From: Theo Kramer
• Re: merge>hash>loop
  • From: Mark Kirkwood
• Re: Blocks read for index scans
  • From: Mark Kirkwood
• Re: merge>hash>loop
  • From: Tom Lane
• Re: merge>hash>loop
  • From: Jim C. Nasby
• Re: Blocks read for index scans
  • From: Jim C. Nasby
• Re: merge>hash>loop
  • From: Mark Kirkwood
• Re: Blocks read for index scans
  • From: Terje Elde
• Re: SELECT FOR UPDATE performance is bad
  • From: Christopher Kings-Lynne
• Re: Planner doesn't chose Index - (slow select)
  • From: Tom Lane
• Planner doesn't chose Index - (slow select)
  • From: patrick keshishian
• Re: merge>hash>loop
  • From: Tom Lane
• Re: merge>hash>loop
  • From: Jim C. Nasby
• Re: merge>hash>loop
  • From: Jim C. Nasby
• Re: Multicolumn order by
  • From: Jim C. Nasby
• Re: Multicolumn order by
  • From: Tom Lane
• Re: creating of temporary table takes very long
  • From: Tom Lane
• Multicolumn order by
  • From: Theo Kramer
• Re: creating of temporary table takes very long
  • From: Jim C. Nasby
• Re: merge>hash>loop
  • From: Tom Lane
• Re: merge>hash>loop
  • From: Tom Lane
• Re: merge>hash>loop
  • From: Jim C. Nasby
• Re: pg_toast size
  • From: Jim C. Nasby
• Re: Inserts optimization?
  • From: Jim C. Nasby
• Re: Inserts optimization?
  • From: Jim C. Nasby
• Re: Slow query - possible bug?
  • From: Gavin Hamill
• Re: Blocks read for index scans
  • From: Jim C. Nasby
• Re: Blocks read for index scans
  • From: Jim C. Nasby
• Re: index is not used if I include a function that returns current time in my query
  • From: Jim C. Nasby
• Re: Slow query - possible bug?
  • From: Tom Lane
• Re: Slow query - possible bug?
  • From: Gavin Hamill
• Re: Slow query - possible bug?
  • From: Tom Lane
• Re: FOREIGN KEYS vs PERFORMANCE
  • From: Rodrigo Sakai
• Re: SELECT FOR UPDATE performance is bad
  • From: PFC
• Re: [bulk] Re: [bulk] Re: Problem with LIKE-Performance
  • From: Tarabas (Manuel Rorarius)
• Re: [bulk] Re: Problem with LIKE-Performance
  • From: Richard Huxton
• Re: creating of temporary table takes very long
  • From: Sriram Dandapani
• Re: creating of temporary table takes very long
  • From: Tom Lane
• Re: [bulk] Re: Problem with LIKE-Performance
  • From: Tarabas (Manuel Rorarius)
• Re: Problem with LIKE-Performance
  • From: Tom Lane
• Re: [bulk] RE: Problem with LIKE-Performance
  • From: Tarabas (Manuel Rorarius)
• Re: Problem with LIKE-Performance
  • From: Guido Neitzer
• Re: Problem with LIKE-Performance
  • From: REISS Thomas DSIC DESP
• Re: Problem with LIKE-Performance
  • From: Hakan Kocaman
• Re: Problem with LIKE-Performance
  • From: Tarabas (Manuel Rorarius)
• Re: SELECT FOR UPDATE performance is bad
  • From: Tom Lane
• Re: Problem with LIKE-Performance
  • From: Tom Lane
• Re: Problem with LIKE-Performance
  • From: Tarabas (Manuel Rorarius)
• Re: Problem with LIKE-Performance
  • From: Dave Dutcher
• Problem with LIKE-Performance
  • From: Tarabas (Manuel Rorarius)
• Re: Migration study, step 2: rewriting queries
  • From: Tom Lane
• Re: SELECT FOR UPDATE performance is bad
  • From: Tom Lane
• SELECT FOR UPDATE performance is bad
  • From: Mario Splivalo
• Re: Inserts optimization?
  • From: Magnus Hagander
• Re: merge>hash>loop
  • From: Markus Schaber
• Re: Inserts optimization?
  • From: Markus Schaber
• Re: Migration study, step 2: rewriting queries
  • From: Mikael Carneholm
• Re: Slow query - possible bug?
  • From: Gavin Hamill
• Re: slow cursor
  • From: Luckys
• Re: creating of temporary table takes very long
  • From: Sriram Dandapani
• Re: creating of temporary table takes very long
  • From: Sriram Dandapani
• Re: creating of temporary table takes very long
  • From: Tom Lane
• Re: creating of temporary table takes very long
  • From: Sriram Dandapani
• creating of temporary table takes very long
  • From: Sriram Dandapani
• slow cursor
  • From: Sriram Dandapani
• Re: Migration study, step 2: rewriting queries
  • From: Tom Lane
• Migration study, step 2: rewriting queries
  • From: Mikael Carneholm
• Re: Inserts optimization?
  • From: Francisco Reyes
• Re: Inserts optimization?
  • From: Francisco Reyes
• Re: Inserts optimization?
  • From: Francisco Reyes
• Re: Inserts optimization?
  • From: Gábriel Ákos
• Re: Inserts optimization?
  • From: Gábriel Ákos
• Re: Inserts optimization?
  • From: Francisco Reyes
• Re: Inserts optimization?
  • From: Scott Marlowe
• Re: Inserts optimization?
  • From: Francisco Reyes
• Re: Inserts optimization?
  • From: Michael Stone
• Re: bad performance on Solaris 10
  • From: Josh Berkus
• Re: Inserts optimization?
  • From: Francisco Reyes
• Re: pgmemcache
  • From: Christian Storm
• Re: Inserts optimization?
  • From: Francisco Reyes
• Re: merge>hash>loop
  • From: Tom Lane
• Re: merge>hash>loop
  • From: Ian Westmacott
• Re: Inserts optimization?
  • From: Tom Lane
• Re: merge>hash>loop
  • From: Tom Lane
• Re: Inserts optimization?
  • From: Francisco Reyes
• merge>hash>loop
  • From: Ian Westmacott
• Re: Blocks read for index scans
  • From: Tom Lane
• Re: bad performance on Solaris 10
  • From: Jignesh K. Shah
• pg_toast size
  • From: Julien Drouard
• Re: Inserts optimization?
  • From: Marc Cousin
• Re: Inserts optimization?
  • From: Michael Stone
• Re: Inserts optimization?
  • From: Francisco Reyes
• Re: pg 7.4.x - pg_restore impossibly slow
  • From: patrick keshishian
• Re: pg 7.4.x - pg_restore impossibly slow
  • From: patrick keshishian
• Re: Blocks read for index scans
  • From: Terje Elde
• Re: pg 7.4.x - pg_restore impossibly slow
  • From: Jim C. Nasby
• Re: Blocks read for index scans
  • From: Jim C. Nasby
• Re: Inserts optimization?
  • From: Jim C. Nasby
• Re: pg 7.4.x - pg_restore impossibly slow
  • From: Tom Lane
• Re: pg 7.4.x - pg_restore impossibly slow
  • From: patrick keshishian
• Re: pgmemcache
  • From: Tom Lane
• Re: Blocks read for index scans
  • From: Tom Lane
• Re: pgmemcache
  • From: Greg Stark
• Re: pgmemcache
  • From: PFC
• Re: multi column query
  • From: Sriram Dandapani
• Re: bad performance on Solaris 10
  • From: Merlin Moncure
• Re: Inserts optimization?
  • From: Francisco Reyes
• Re: Blocks read for index scans
  • From: Jim Nasby
• Re: Inserts optimization?
  • From: Francisco Reyes
• Re: pgmemcache
  • From: Jim Nasby
• Blocks read for index scans
  • From: Jim Nasby
• Re: bad performance on Solaris 10
  • From: Robert Lor
• Re: pgmemcache
  • From: Tom Lane
• Re: pgmemcache
  • From: Christian Storm
• Re: multi column query
  • From: Jim Nasby
• Re: index is not used if I include a function that returns current time in my query
  • From: Tom Lane
• Re: Better index stategy for many fields with few values
  • From: Oscar Picasso
• Re: Slow query - possible bug?
  • From: Tom Lane
• index is not used if I include a function that returns current time in my query
  • From: Cristian Veronesi
• Re: pg 8.1.3, AIX, huge box, painfully slow.
  • From: Gavin Hamill
• Re: pgmemcache
  • From: Markus Schaber
• Re: Better index stategy for many fields with few values
  • From: Markus Schaber
• Re: Slow query - possible bug?
  • From: Richard Huxton
• Re: Slow query - possible bug?
  • From: Gavin Hamill
• Re: Slow query - possible bug?
  • From: chris smith
• Slow query - possible bug?
  • From: Gavin Hamill
• index is not used if I include a function that returns current time in my query
  • From: Cris Carampa
• Re: Better index stategy for many fields with few values
  • From: Markus Schaber
• Re: Better index stategy for many fields with few values
  • From: Markus Schaber
• Re: bad performance on Solaris 10
  • From: Bruce Momjian
• Re: bad performance on Solaris 10
  • From: Tom Lane
• Re: pg 7.4.x - pg_restore impossibly slow
  • From: Tom Lane
• Re: Inserts optimization?
  • From: Tom Lane
• Re: Sun Fire T2000 and PostgreSQL 8.1.3
  • From: Bruce Momjian
• Re: bad performance on Solaris 10
  • From: Jignesh K. Shah
• Re: FOREIGN KEYS vs PERFORMANCE
  • From: Craig A. James
• pg 7.4.x - pg_restore impossibly slow
  • From: patrick keshishian
• Re: Inserts optimization?
  • From: Chris
• Inserts optimization?
  • From: Francisco Reyes
• Re: multi column query
  • From: Jim C. Nasby
• Re: pgmemcache
  • From: Tom Lane
• multi column query
  • From: Sriram Dandapani
• Re: pgmemcache
  • From: Jim C. Nasby
• Re: pgmemcache
  • From: Josh Berkus
• Re: Better index stategy for many fields with few values
  • From: Jim Nasby
• Re: bad performance on Solaris 10
  • From: Josh Berkus
• Re: Better index stategy for many fields with few
  • From: Luke Lonergan
• Re: bad performance on Solaris 10
  • From: Luke Lonergan
• Re: FOREIGN KEYS vs PERFORMANCE
  • From: Jim C. Nasby
• Re: Better index stategy for many fields with few values
  • From: Jim C. Nasby
• Re: bad performance on Solaris 10
  • From: Bruce Momjian
• Re: FOREIGN KEYS vs PERFORMANCE
  • From: Craig A. James
• Re: FOREIGN KEYS vs PERFORMANCE
  • From: Jim C. Nasby
• Re: FOREIGN KEYS vs PERFORMANCE
  • From: Jim C. Nasby
• Re: FOREIGN KEYS vs PERFORMANCE
  • From: Scott Marlowe
• Re: FOREIGN KEYS vs PERFORMANCE
  • From: PFC
• Re: FOREIGN KEYS vs PERFORMANCE
  • From: Michael Glaesemann
• Re: FOREIGN KEYS vs PERFORMANCE
  • From: Merlin Moncure
• Re: FOREIGN KEYS vs PERFORMANCE
  • From: Rodrigo Sakai
• Re: FOREIGN KEYS vs PERFORMANCE
  • From: Craig A. James
• Re: FOREIGN KEYS vs PERFORMANCE
  • From: Markus Schaber
• Re: Sequencial scan instead of using index
  • From: Harry Hehl
• Re: Better index stategy for many fields with few values
  • From: Markus Schaber
• Re: FOREIGN KEYS vs PERFORMANCE
  • From: PFC
• Re: pgmemcache
  • From: PFC
• Re: FOREIGN KEYS vs PERFORMANCE
  • From: Tom Lane
• Re: Restore performance?
  • From: Christopher Kings-Lynne
• Re: FOREIGN KEYS vs PERFORMANCE
  • From: Jim C. Nasby
• Re: FOREIGN KEYS vs PERFORMANCE
  • From: Michael Glaesemann
• Re: freebsd/softupdates for data dir
  • From: Jim C. Nasby
• Re: pgmemcache
  • From: Jim C. Nasby
• Re: Sequencial scan instead of using index
  • From: Tom Lane
• Re: Sequencial scan instead of using index
  • From: Harry Hehl
• Re: Sequencial scan instead of using index
  • From: markir
• Re: Sequencial scan instead of using index
  • From: markir
• Re: Encouraging multi-table join order
  • From: Tom Lane
• Re: Encouraging multi-table join order
  • From: Dan Harris
• Re: Encouraging multi-table join order
  • From: Tom Lane
• Re: Stored Procedure Performance
  • From: Merlin Moncure
• Re: Encouraging multi-table join order
  • From: Dan Harris
• Re: FOREIGN KEYS vs PERFORMANCE
  • From: Scott Marlowe
• FOREIGN KEYS vs PERFORMANCE
  • From: Rodrigo Sakai
• Re: Indexes with descending date columns
  • From: Markus Schaber
• Re: Stored Procedure Performance
  • From: Alvaro Herrera
• Re: Stored Procedure Performance
  • From: H.J. Sanders
• Re: Stored Procedure Performance
  • From: Christopher Browne
• Re: Takes too long to fetch the data from database
  • From: Tom Lane
• Re: Stored Procedure Performance
  • From: Merlin Moncure
• Re: Takes too long to fetch the data from database
  • From: Merlin Moncure
• Re: Restore performance?
  • From: Jesper Krogh
• Re: Takes too long to fetch the data from database
  • From: Richard Huxton
• Re: Stored Procedure Performance
  • From: Richard Huxton
• Re: Stored Procedure Performance
  • From: Rajesh Kumar Mallah
• Re: Stored Procedure Performance
  • From: hubert depesz lubaczewski
• Stored Procedure Performance
  • From: Simon Dale
• Re: Takes too long to fetch the data from database
  • From: soni de
• Re: slow "IN" clause
  • From: Vinko Vrsalovic
• Re: Encouraging multi-table join order
  • From: Tom Lane
• Re: Encouraging multi-table join order
  • From: Dan Harris
• Re: Encouraging multi-table join order
  • From: Tom Lane
• Re: bad performance on Solaris 10
  • From: Chris Mair
• Re: OT: Data structure design question: How do they count so fast?
  • From: Brendan Duddridge
• Re: pg 8.1.3, AIX, huge box, painfully slow.
  • From: Brad Nicholson
• Encouraging multi-table join order
  • From: Dan Harris
• Re: Restore performance?
  • From: Vivek Khera
• Re: Takes too long to fetch the data from database
  • From: Joshua D. Drake
• Re: Better index stategy for many fields with few values
  • From: PFC
• Re: Restore performance?
  • From: PFC
• Better index stategy for many fields with few values
  • From: Oscar Picasso
• Re: Restore performance?
  • From: Alvaro Herrera
• Re: Restore performance?
  • From: Rajesh Kumar Mallah
• Re: Takes too long to fetch the data from database
  • From: Rajesh Kumar Mallah
• Re: Restore performance?
  • From: Jesper Krogh
• Re: Restore performance?
  • From: Rajesh Kumar Mallah
• Re: Restore performance?
  • From: Rajesh Kumar Mallah
• Re: pg 8.1.3, AIX, huge box, painfully slow.
  • From: Tom Lane
• Re: Restore performance?
  • From: Tom Lane
• Re:
  • From: Ragnar
• Re: pg 8.1.3, AIX, huge box, painfully slow.
  • From: Gavin Hamill
• Re: pg 8.1.3, AIX, huge box, painfully slow.
  • From: Simon Riggs
• Re: OT: Data structure design question: How do they count
  • From: Richard Huxton
• Re: pg 8.1.3, AIX, huge box, painfully slow.
  • From: Richard Huxton
• Re: Restore performance?
  • From: Marcin Mańk
• Re: Restore performance?
  • From: Jesper Krogh
• Re: Restore performance?
  • From: Andreas Pflug
• Dump restore performance 7.3 -> 8.1
  • From: Jesper Krogh
• Re: Restore performance?
  • From: Luke Lonergan
• Restore performance?
  • From: Jesper Krogh
• Re:
  • From: Doron Baranes
• Takes too long to fetch the data from database
  • From: soni de
• Re: serious problems with vacuuming databases
  • From: Ahmad Fajar
• Re: OT: Data structure design question: How do they count so fast?
  • From: Brendan Duddridge
• Re: slow "IN" clause
  • From: Qingqing Zhou
• slow "IN" clause
  • From: FavoYang
• Re: serious problems with vacuuming databases
  • From: Alvaro Herrera
• Re: serious problems with vacuuming databases
  • From: Tomas Vondra
• Re: serious problems with vacuuming databases
  • From: Alvaro Herrera
• Re: serious problems with vacuuming databases
  • From: Tomas Vondra
• Re: serious problems with vacuuming databases
  • From: Tomas Vondra
• Re: serious problems with vacuuming databases
  • From: Tomas Vondra
• Re: Scaling up PostgreSQL in Multiple CPU / Dual Core
  • From: Bruce Momjian
• Re: serious problems with vacuuming databases
  • From: Tom Lane
• Re: serious problems with vacuuming databases
  • From: Alvaro Herrera
• serious problems with vacuuming databases
  • From: Tomas Vondra
• Re: pls reply ASAP
  • From: Rajesh Kumar Mallah
• Re:
  • From: Ragnar
• Re:
  • From: Luckys
• [no subject]
  • From: Doron Baranes
• pls reply ASAP
  • From: Chethana, Rao (IE10)
• OT: Data structure design question: How do they count so fast?
  • From: Brendan Duddridge
• Re: Indexes with descending date columns
  • From: Bruce Momjian
• Re: pg 8.1.3, AIX, huge box, painfully slow.
  • From: Gavin Hamill
• Re: pg 8.1.3, AIX, huge box, painfully slow.
  • From: Gavin Hamill
• Re: pg 8.1.3, AIX, huge box, painfully slow.
  • From: Tom Lane
• Re: pg 8.1.3, AIX, huge box, painfully slow.
  • From: Luke Lonergan
• Re: pg 8.1.3, AIX, huge box, painfully slow.
  • From: Tom Lane
• Re: pg 8.1.3, AIX, huge box, painfully slow.
  • From: Gavin Hamill
• Re: pg 8.1.3, AIX, huge box, painfully slow.
  • From: Tom Lane
• Re: pg 8.1.3, AIX, huge box, painfully slow.
  • From: Luke Lonergan
• Re: pg 8.1.3, AIX, huge box, painfully slow.
  • From: Tom Lane
• Re: pg 8.1.3, AIX, huge box, painfully slow.
  • From: Tom Lane
• Re: pg 8.1.3, AIX, huge box, painfully slow.
  • From: Luke Lonergan
• Re: pg 8.1.3, AIX, huge box, painfully slow.
  • From: Gavin Hamill
• Re: pg 8.1.3, AIX, huge box, painfully slow.
  • From: Gavin Hamill
• Re: pg 8.1.3, AIX, huge box, painfully slow.
  • From: Gavin Hamill
• Re: pg 8.1.3, AIX, huge box, painfully slow.
  • From: Gábriel Ákos
• Re: pg 8.1.3, AIX, huge box, painfully slow.
  • From: Greg Stark
• Re: pg 8.1.3, AIX, huge box, painfully slow.
  • From: Scott Marlowe
• Re: pg 8.1.3, AIX, huge box, painfully slow.
  • From: D'Arcy J.M. Cain
• Re: pg 8.1.3, AIX, huge box, painfully slow.
  • From: Tom Lane
• Re: pg 8.1.3, AIX, huge box, painfully slow.
  • From: Gavin Hamill
• Re: pg 8.1.3, AIX, huge box, painfully slow.
  • From: Gavin Hamill
• Re: bad performance on Solaris 10
  • From: Chris Mair
• Re: Same SQL, 104296ms of difference between 7.4.12 and
  • From: Rafael Martinez
• Re: pg 8.1.3, AIX, huge box, painfully slow.
  • From: Scott Marlowe
• Re: pg 8.1.3, AIX, huge box, painfully slow.
  • From: Tom Lane
• pg 8.1.3, AIX, huge box, painfully slow.
  • From: Gavin Hamill
• Re: Same SQL, 104296ms of difference between 7.4.12 and 8.0.7
  • From: Tom Lane
• Re: Loading the entire DB into RAM
  • From: PFC
• Re: Loading the entire DB into RAM
  • From: Scott Marlowe
• Re: Loading the entire DB into RAM
  • From: Merlin Moncure
• Re: Same SQL, 104296ms of difference between 7.4.12 and 8.0.7
  • From: Tom Lane
• Re: Loading the entire DB into RAM
  • From: Tom Lane
• Re: Spotting planner errors (was Re: Query planner is using
  • From: Richard Huxton
• Re: Spotting planner errors (was Re: Query planner is using wrong index.)
  • From: Tom Lane
• Spotting planner errors (was Re: Query planner is using wrong index.)
  • From: Richard Huxton
• Re: Loading the entire DB into RAM
  • From: Matt Davies | Postgresql List
• Re: Loading the entire DB into RAM
  • From: Charles A. Landemaine
• Re: Same SQL, 104296ms of difference between 7.4.12 and
  • From: Rafael Martinez
• Re: Same SQL, 104296ms of difference between 7.4.12 and
  • From: Richard Huxton
• Loading the entire DB into RAM
  • From: Charles A. Landemaine
• Re: Query planner is using wrong index.
  • From: Tom Lane
• Re: Same SQL, 104296ms of difference between 7.4.12 and
  • From: Rafael Martinez Guerrero
• Re: Same SQL, 104296ms of difference between 7.4.12 and
  • From: Richard Huxton
• Same SQL, 104296ms of difference between 7.4.12 and 8.0.7
  • From: Rafael Martinez Guerrero
• Re: Query planner is using wrong index.
  • From: Brian Herlihy
• Re: Query planner is using wrong index.
  • From: Tom Lane
• Re: Query planner is using wrong index.
  • From: Brian Herlihy
• Re: Query planner is using wrong index.
  • From: Dave Dutcher
• Re: Query planner is using wrong index.
  • From: Brian Herlihy
• Re: Sun Fire T2000 and PostgreSQL 8.1.3
  • From: Jignesh K. Shah
• Re: Sun Fire T2000 and PostgreSQL 8.1.3
  • From: Jignesh K. Shah
• Re: CURSOR OR OFFSET/LIMIT
  • From: John DeSoi
• Re: Query planner is using wrong index.
  • From: Ragnar
• Re: Sun Fire T2000 and PostgreSQL 8.1.3
  • From: Luke Lonergan
• Re: Sun Fire T2000 and PostgreSQL 8.1.3
  • From: Vivek Khera
• Re: Sun Fire T2000 and PostgreSQL 8.1.3
  • From: Vivek Khera
• Re: Sun Fire T2000 and PostgreSQL 8.1.3
  • From: Vivek Khera
• CURSOR OR OFFSET/LIMIT
  • From: Kaloyan Iliev
• Re: Query planner is using wrong index.
  • From: Brian Herlihy
• Re: Sun Fire T2000 and PostgreSQL 8.1.3
  • From: Matthew Nuzum
• Re: freebsd/softupdates for data dir
  • From: Vivek Khera
• Re: Intel C/C++ Compiler Tests (fwd)
  • From: Bruce Momjian
• Re: Query planner is using wrong index.
  • From: Ragnar
• Re: Sun Fire T2000 and PostgreSQL 8.1.3
  • From: Juan Casero (FL FLC)
• Re: Query planner is using wrong index.
  • From: Brian Herlihy
• Re: Sun Fire T2000 and PostgreSQL 8.1.3
  • From: Markus Schaber
• Maintenance_work_mem influence on queries
  • From: luchot
• Re: Query planner is using wrong index.
  • From: Ragnar
• Query planner is using wrong index.
  • From: Brian Herlihy
• Re: Sun Fire T2000 and PostgreSQL 8.1.3
  • From: Leigh Dyer
• Re: bad performance on Solaris 10
  • From: Robert Lor
• Re: Sun Fire T2000 and PostgreSQL 8.1.3
  • From: Miguel
• Re: Sun Fire T2000 and PostgreSQL 8.1.3
  • From: Josh Berkus
• Re: Sun Fire T2000 and PostgreSQL 8.1.3
  • From: Mark Kirkwood
• Re: bad performance on Solaris 10
  • From: Josh Berkus
• Re: bad performance on Solaris 10
  • From: Josh Berkus
• Re: Sun Fire T2000 and PostgreSQL 8.1.3
  • From: Juan Casero (FL FLC)
• Re: bad performance on Solaris 10
  • From: Chris Mair
• Re: Sun Fire T2000 and PostgreSQL 8.1.3
  • From: Leigh Dyer
• Re: Sun Fire T2000 and PostgreSQL 8.1.3
  • From: Luke Lonergan
• Re: Sun Fire T2000 and PostgreSQL 8.1.3
  • From: Leigh Dyer
• Re: Sun Fire T2000 and PostgreSQL 8.1.3
  • From: Robert Lor
• Re: Sun Fire T2000 and PostgreSQL 8.1.3
  • From: Robert Lor
• Re: Sun Fire T2000 and PostgreSQL 8.1.3
  • From: Anthony Ransley
• Re: bad performance on Solaris 10
  • From: Mark Kirkwood
• Re: Sun Fire T2000 and PostgreSQL 8.1.3
  • From: Marcelo Tada
• Re: Sun Fire T2000 and PostgreSQL 8.1.3
  • From: Luke Lonergan
• Re: Sun Fire T2000 and PostgreSQL 8.1.3
  • From: Juan Casero (FL FLC)
• Re: bad performance on Solaris 10
  • From: Chris Mair
• Re: bad performance on Solaris 10
  • From: Chris Mair
• Re: bad performance on Solaris 10
  • From: Mark Kirkwood
• Re: bad performance on Solaris 10
  • From: Chris Mair
• Re: Sun Fire T2000 and PostgreSQL 8.1.3
  • From: Chris Browne
• Re: Sun Fire T2000 and PostgreSQL 8.1.3
  • From: Chris Browne
• Re: Sun Fire T2000 and PostgreSQL 8.1.3
  • From: Tom Lane
• Re: Sun Fire T2000 and PostgreSQL 8.1.3
  • From: Scott Marlowe
• Re: freebsd/softupdates for data dir
  • From: Jim Nasby
• Re: Sun Fire T2000 and PostgreSQL 8.1.3
  • From: Josh Berkus
• Re: Sun Fire T2000 and PostgreSQL 8.1.3
  • From: August Zajonc
• Re: bad performance on Solaris 10
  • From: Luke Lonergan
• Re: Sun Fire T2000 and PostgreSQL 8.1.3
  • From: Luke Lonergan
• Re: bad performance on Solaris 10
  • From: Alvaro Herrera
• Re: Sun Fire T2000 and PostgreSQL 8.1.3
  • From: Juan Casero (FL FLC)
• Re: bad performance on Solaris 10
  • From: Luke Lonergan
• Re: Sun Fire T2000 and PostgreSQL 8.1.3
  • From: Luke Lonergan
• Re: bad performance on Solaris 10
  • From: Chris Mair
• Re: Sun Fire T2000 and PostgreSQL 8.1.3
  • From: Juan Casero (FL FLC)
• Re: Sun Fire T2000 and PostgreSQL 8.1.3
  • From: Luke Lonergan
• Re: Sun Fire T2000 and PostgreSQL 8.1.3
  • From: Tom Lane
• Sun Fire T2000 and PostgreSQL 8.1.3
  • From: Juan Casero (FL FLC)
• Re: Query runs too long for indexed tables
  • From: Tom Lane
• Re: Query runs too long for indexed tables
  • From: PFC
• Re: Query runs too long for indexed tables
  • From: Andrus
• Re: Query runs too long for indexed tables
  • From: PFC
• Re: Query runs too long for indexed tables
  • From: Andrus
• Re: The order of fields around the "=" in the WHERE
  • From: Mike Quinn
• Re: Query using SeqScan instead of IndexScan
  • From: Jim Nasby
• Re: Query using SeqScan instead of IndexScan
  • From: Jim Nasby
• Re: Query runs too long for indexed tables
  • From: Marc Morin
• Re: Query runs too long for indexed tables
  • From: Marc Morin
• Re: Query runs too long for indexed tables
  • From: Scott Marlowe
• Query runs too long for indexed tables
  • From: Andrus
• Re: The order of fields around the "=" in the WHERE
  • From: Mike Quinn
• Re: vacuum full seems to hang on very small table
  • From: Simon Riggs
• Re: vacuum full seems to hang on very small table
  • From: Brad Nicholson
• vacuum full seems to hang on very small table
  • From: Dan Harris
• Re: freebsd/softupdates for data dir
  • From: Vivek Khera
• pgmemcache
  • From: C Storm
• Re: bad performance on Solaris 10
  • From: Josh Berkus
• Re: bad performance on Solaris 10
  • From: Mark Kirkwood
• Re: bad performance on Solaris 10
  • From: Luke Lonergan
• Re: freebsd/softupdates for data dir
  • From: Mark Kirkwood
• freebsd/softupdates for data dir
  • From: Miguel
• Re: bad performance on Solaris 10
  • From: Josh Berkus
• bad performance on Solaris 10
  • From: Chris Mair
• Re: The order of fields around the "=" in the WHERE conditions
  • From: Tom Lane
• Re: The order of fields around the "=" in the WHERE conditions
  • From: Tom Lane
• The order of fields around the "=" in the WHERE conditions
  • From: Mike Quinn
• Re: optimizing db for small table with tons of updates
  • From: Kenji Morishige
• Re: optimizing db for small table with tons of updates
  • From: Tom Lane
• Re: optimizing db for small table with tons of updates
  • From: Kenji Morishige
• Re: optimizing db for small table with tons of updates
  • From: Alvaro Herrera
• Re: optimizing db for small table with tons of updates
  • From: Kenji Morishige
• Re: optimizing db for small table with tons of updates
  • From: Tom Lane
• Re: optimizing db for small table with tons of updates
  • From: Rajesh Kumar Mallah
• Re: optimizing db for small table with tons of updates
  • From: Josh Berkus
• optimizing db for small table with tons of updates
  • From: Kenji Morishige
• Re: Measuring the execution time of functions within functions...
  • From: Jerry Sievers
• Re: Measuring the execution time of functions within functions...
  • From: Alvaro Herrera
• Measuring the execution time of functions within functions...
  • From: Mario Splivalo
• Re: Trigger vs Rule
  • From: Ключников А.С.
• Re: Trigger vs Rule
  • From: Niklas Johansson
• Re: Query using SeqScan instead of IndexScan
  • From: Brendan Duddridge
• Re: Query using SeqScan instead of IndexScan
  • From: Josh Berkus
• Re: Trigger vs Rule
  • From: Niklas Johansson
• Re: index not used again
  • From: Stephan Szabo
• Re: index not used again
  • From: Jan Kesten
• Re: Logging SQL queries to optimize them ?
  • From: Qingqing Zhou
• Re: Large Binary Objects Middleware
  • From: Qingqing Zhou
• Re: statistics buffer is full
  • From: Qingqing Zhou
• Trigger vs Rule
  • From: Ключников А.С.
• Re: Query using SeqScan instead of IndexScan
  • From: Tom Lane
• Re: Query using SeqScan instead of IndexScan
  • From: Mark Kirkwood
• Re: Query using SeqScan instead of IndexScan
  • From: Alvaro Herrera
• Re: Query using SeqScan instead of IndexScan
  • From: chris smith
• Re: Query using SeqScan instead of IndexScan
  • From: chris smith
• Re: [Solved] Slow performance on Windows .NET and OleDb
  • From: Merlin Moncure
• Re: Query using SeqScan instead of IndexScan
  • From: Brendan Duddridge
• Re: Query using SeqScan instead of IndexScan
  • From: Jim C. Nasby
• Re: [Solved] Slow performance on Windows .NET and OleDb
  • From: Antoine
• Re: Query using SeqScan instead of IndexScan
  • From: Brendan Duddridge
• Re: Query using SeqScan instead of IndexScan
  • From: chris smith
• Re: Query using SeqScan instead of IndexScan
  • From: Brendan Duddridge
• Re: [Solved] Slow performance on Windows .NET and OleDb
  • From: Magnus Hagander
• Re: [Solved] Slow performance on Windows .NET and OleDb
  • From: Antoine
• Re: un-'vacuum analyse'
  • From: Tom Lane
• un-'vacuum analyse'
  • From: Frederic Back
• Re: Query using SeqScan instead of IndexScan
  • From: Jim C. Nasby
• Re: Indexes with descending date columns
  • From: Jim C. Nasby
• Re: simple join uses indexes, very slow
  • From: Jim C. Nasby
• Re: index not used again
  • From: Stephan Szabo
• index not used again
  • From: Jan Kesten
• Re: Decide between Postgresql and Mysql (help of
  • From: Guido Neitzer
• Re: Decide between Postgresql and Mysql (help of
  • From: Philippe Marzin
• Re: Decide between Postgresql and Mysql (help of
  • From: Chris Browne
• Re: Decide between Postgresql and Mysql (help of
  • From: Steinar H. Gunderson
• Re: Decide between Postgresql and Mysql (help of
  • From: PFC
• Re: CREATE INDEX rather sluggish
  • From: Gavin Hamill
• Re: CREATE INDEX rather sluggish
  • From: Gavin Hamill
• Re: Decide between Postgresql and Mysql (help of
  • From: Scott Marlowe
• Re: Decide between Postgresql and Mysql (help of
  • From: Chris Browne
• Re: Index scan startup time
  • From: Simon Riggs
• Re: CREATE INDEX rather sluggish
  • From: Simon Riggs
• Re: Index scan startup time
  • From: Tom Lane
• Re: CREATE INDEX rather sluggish
  • From: Tom Lane
• Re: Index scan startup time
  • From: Peter Eisentraut
• Re: [Solved] Slow performance on Windows .NET and OleDb
  • From: Dave Dutcher
• Re: Index scan startup time
  • From: Tom Lane
• Automatic tuning of postgresql.conf parameters?
  • From: Mattias Kregert
• Re: Index scan startup time
  • From: Michael Stone
• Re: Index scan startup time
  • From: Steinar H. Gunderson
• Re: Index scan startup time
  • From: Peter Eisentraut
• Re: Index scan startup time
  • From: Steinar H. Gunderson
• Re: Index scan startup time
  • From: Michael Stone
• Re: Index scan startup time
  • From: Markus Schaber
• Re: Index scan startup time
  • From: Steinar H. Gunderson
• Re: Index scan startup time
  • From: Peter Eisentraut
• Re: Index scan startup time
  • From: Peter Eisentraut
• Re: Index scan startup time
  • From: Michael Stone
• Re: Index scan startup time
  • From: Steinar H. Gunderson
• Index scan startup time
  • From: Peter Eisentraut
• Re: Decide between Postgresql and Mysql (help of
  • From: Markus Schaber
• CREATE INDEX rather sluggish
  • From: Gavin Hamill
• [Solved] Slow performance on Windows .NET and OleDb
  • From: Greg Quinn
• Re: Query using SeqScan instead of IndexScan
  • From: Josh Berkus
• Re: Database possible corruption , unsolvable mystery
  • From: Josh Berkus
• Re: Query using SeqScan instead of IndexScan
  • From: Brendan Duddridge
• Query using SeqScan instead of IndexScan
  • From: Brendan Duddridge
• Re: Decide between Postgresql and Mysql (help of
  • From: Gorshkov
• Re: Decide between Postgresql and Mysql (help of
  • From: Craig A. James
• Re: Decide between Postgresql and Mysql (help of
  • From: Gorshkov
• Re: Decide between Postgresql and Mysql (help of
  • From: Craig A. James
• Re: Slow performance on Windows .NET and OleDb
  • From: Christopher Kings-Lynne
• Re: Decide between Postgresql and Mysql (help of
  • From: Gorshkov
• Re: Database possible corruption , unsolvable mystery
  • From: Eric Lauzon
• Re: Database possible corruption , unsolvable mystery
  • From: stef
• Re: Database possible corruption , unsolvable mystery
  • From: Eric Lauzon
• Re: Database possible corruption , unsolvable mystery
  • From: Mark Lewis
• Re: Database possible corruption , unsolvable mystery
  • From: Richard Huxton
• Database possible corruption , unsolvable mystery
  • From: Eric Lauzon
• Re: Decide between Postgresql and Mysql (help of
  • From: Vivek Khera
• Re: Decide between Postgresql and Mysql (help of
  • From: Vivek Khera
• Re: Decide between Postgresql and Mysql (help of comunity)
  • From: Vivek Khera
• Re: simple join uses indexes, very slow
  • From: george young
• Re: Slow performance on Windows .NET and OleDb
  • From: Merlin Moncure
• Re: Decide between Postgresql and Mysql (help of
  • From: Merlin Moncure
• statistics buffer is full
  • From: Gábriel Ákos
• Re: Slow performance on Windows .NET and OleDb
  • From: PFC
• Re: Slow performance on Windows .NET and OleDb
  • From: Markus Schaber
• Re: Slow performance on Windows .NET and OleDb
  • From: Greg Quinn
• Re: Indexes with descending date columns
  • From: Theo Kramer
• Re: Slow performance on Windows .NET and OleDb
  • From: Chris
• Re: Slow performance on Windows .NET and OleDb
  • From: Ruben Rubio Rey
• Re: Slow performance on Windows .NET and OleDb
  • From: Greg Quinn
• Re: Slow performance on Windows .NET and OleDb
  • From: Greg Quinn
• Re: simple join uses indexes, very slow
  • From: stef
• Re: simple join uses indexes, very slow
  • From: Chris
• Re: MVCC intro and benefits docs?
  • From: Qingqing Zhou
• Re: simple join uses indexes, very slow
  • From: Dave Dutcher
• Re: MVCC intro and benefits docs?
  • From: Jim C. Nasby
• Re: Decide between Postgresql and Mysql (help of
  • From: Jim C. Nasby
• Re: Decide between Postgresql and Mysql (help of
  • From: Jim C. Nasby
• Re: Decide between Postgresql and Mysql (help of
  • From: PFC
• Re: Decide between Postgresql and Mysql (help of
  • From: PFC
• Re: simple join uses indexes, very slow
  • From: george young
• Re: Decide between Postgresql and Mysql (help of
  • From: Chris Travers
• Re: Decide between Postgresql and Mysql (help of
  • From: Scott Marlowe
• Re: Decide between Postgresql and Mysql (help of
  • From: PFC
• Re: Decide between Postgresql and Mysql (help of
  • From: Marcos
• MVCC intro and benefits docs?
  • From: Antoine
• Re: Decide between Postgresql and Mysql (help of
  • From: Scott Marlowe
• Re: Decide between Postgresql and Mysql (help of comunity)
  • From: Madison Kelly
• Decide between Postgresql and Mysql (help of comunity)
  • From: Marcos
• Re: simple join uses indexes, very slow
  • From: Simon Riggs
• Re: Slow performance on Windows .NET and OleDb
  • From: Joshua D. Drake
• Re: Massive Inserts Strategies
  • From: Jim C. Nasby
• Re: simple join uses indexes, very slow
  • From: Steinar H. Gunderson
• Re: Slow performance on Windows .NET and OleDb
  • From: Jim C. Nasby
• Re: simple join uses indexes, very slow
  • From: Jim C. Nasby
• Re: count(*) performance
  • From: Jim C. Nasby
• Re: simple join uses indexes, very slow
  • From: Dave Dutcher
• Re: simple join uses indexes, very slow
  • From: Steinar H. Gunderson
• Re: Massive Inserts Strategies
  • From: Markus Schaber
• Re: simple join uses indexes, very slow
  • From: Dave Dutcher
• Re: Massive Inserts Strategies
  • From: ashah
• Re: simple join uses indexes, very slow
  • From: Markus Schaber
• Re: simple join uses indexes, very slow
  • From: george young
• Re: Slow performance on Windows .NET and OleDb
  • From: Merlin Moncure
• Slow performance on Windows .NET and OleDb
  • From: Greg Quinn
• Re: count(*) performance
  • From: Markus Schaber
• Re: simple join uses indexes, very slow
  • From: Simon Riggs
• Re: count(*) performance
  • From: Mikael Carneholm
• Re: count(*) performance
  • From: Tom Lane
• Re: count(*) performance
  • From: Matthew T. O'Connor
• Re: count(*) performance
  • From: Mikael Carneholm
• Large Binary Objects Middleware
  • From: Rodrigo Madera
• Re: count(*) performance
  • From: Guido Neitzer
• Re: count(*) performance
  • From: Alvaro Herrera
• Re: count(*) performance
  • From: Matthew T. O'Connor
• Re: count(*) performance
  • From: Brendan Duddridge
• simple join uses indexes, very slow
  • From: george young
• Re: count(*) performance
  • From: Gábriel Ákos
• Re: count(*) performance
  • From: Luke Lonergan
• Re: count(*) performance
  • From: Gábriel Ákos
• Re: count(*) performance
  • From: Gábriel Ákos
• Re: count(*) performance
  • From: Luke Lonergan
• Re: Query parallelism
  • From: Jim C. Nasby
• Query parallelism
  • From: luchot
• Re: count(*) performance
  • From: Jim C. Nasby
• count(*) performance
  • From: Gábriel Ákos
• Re: [GENERAL] experiences needed - how does Itanium2/1.5GHz(4MB) compare to AMD and Intel CPUs as far as Postgresql is concerned
  • From: Jim C. Nasby
• Re: Array performance
  • From: Ruben Rubio Rey
• Re: Query plan from hell
  • From: Guido Neitzer
• Re: limitation using LIKE on ANY(array)
  • From: K C Lau
• Query plan from hell
  • From: PFC
• Re: Scaling up PostgreSQL in Multiple CPU / Dual Core
  • From: Chris Browne
• Re: Scaling up PostgreSQL in Multiple CPU / Dual Core
  • From: Jim C. Nasby
• Re: Performance problems with multiple layers of functions
  • From: Tom Lane
• Re: Scaling up PostgreSQL in Multiple CPU / Dual Core
  • From: Michael Stone
• Re: Performance problems with multiple layers of functions
  • From: Svenne Krap
• Re: Scaling up PostgreSQL in Multiple CPU / Dual Core
  • From: Chris Browne
• Re: Scaling up PostgreSQL in Multiple CPU / Dual Core
  • From: Chris Browne
• Re: WAL logging of SELECT ... INTO command
  • From: Kris Jurka
• Re: Postmaster using only 4-5% CPU
  • From: Scott Marlowe
• Re: limitation using LIKE on ANY(array)
  • From: Tom Lane
• Re: Performance problems with multiple layers of functions
  • From: Tom Lane
• Re: Array performance
  • From: Tom Lane
• limitation using LIKE on ANY(array)
  • From: K C Lau
• Re: Scaling up PostgreSQL in Multiple CPU / Dual Core
  • From: Luke Lonergan
• Re: Problem with query, server totally unresponsive
  • From: Jim C. Nasby
• Re: Problem with query, server totally unresponsive
  • From: Dave Dutcher
• Re: WAL logging of SELECT ... INTO command
  • From: Jim C. Nasby
• Re: WAL logging of SELECT ... INTO command
  • From: Alvaro Herrera
• Re: Array performance
  • From: Michael Fuhr
• Re: Array performance
  • From: Jim C. Nasby
• Re: Array performance
  • From: Ruben Rubio Rey
• Re: WAL logging of SELECT ... INTO command
  • From: Jim C. Nasby
• Re: Performance problems with multiple layers of functions
  • From: Jim C. Nasby
• Re: Array performance
  • From: Jim C. Nasby
• Performance problems with multiple layers of functions
  • From: Svenne Krap
• Array performance
  • From: Ruben Rubio Rey
• Re: WAL logging of SELECT ... INTO command
  • From: Alvaro Herrera
• Re: Problem with query, server totally unresponsive
  • From: Jim C. Nasby
• Re: Indexes with descending date columns
  • From: Jim C. Nasby
• Re: Postmaster using only 4-5% CPU
  • From: Jim C. Nasby
• Re: Scaling up PostgreSQL in Multiple CPU / Dual Core
  • From: Jim C. Nasby
• Re: WAL logging of SELECT ... INTO command
  • From: Jim C. Nasby
• Re: WAL logging of SELECT ... INTO command
  • From: Jim C. Nasby
• Re: Indexes with descending date columns
  • From: Tom Lane
• Re: Indexes with descending date columns
  • From: Theo Kramer
• Re: Scaling up PostgreSQL in Multiple CPU / Dual Core
  • From: Christopher Browne
• Re: Scaling up PostgreSQL in Multiple CPU / Dual Core
  • From: Scott Marlowe
• Re: Scaling up PostgreSQL in Multiple CPU / Dual Core
  • From: Joshua D. Drake
• Re: Scaling up PostgreSQL in Multiple CPU / Dual Core
  • From: Scott Marlowe
• Re: Scaling up PostgreSQL in Multiple CPU / Dual Core
  • From: Frank Wiles
• Problem with query, forget previous message
  • From: Bendik Rognlien Johansen
• Re: Scaling up PostgreSQL in Multiple CPU / Dual Core Powered Servers
  • From: Christopher Browne
• Re: Indexes with descending date columns
  • From: Alvaro Herrera
• Problem with query, server totally unresponsive
  • From: Bendik Rognlien Johansen
• Re: Indexes with descending date columns
  • From: Theo Kramer
• Re: Postmaster using only 4-5% CPU
  • From: Edoardo Serra
• Scaling up PostgreSQL in Multiple CPU / Dual Core Powered Servers
  • From: Jojo Paderes
• Re: WAL logging of SELECT ... INTO command
  • From: Qingqing Zhou
• Re: WAL logging of SELECT ... INTO command
  • From: Kris Jurka
• Re: Intel C/C++ Compiler Tests
  • From: Luke Lonergan
• Re: planner with index scan cost way off actual cost,
  • From: Guillaume Cottenceau
• Re: WAL logging of SELECT ... INTO command
  • From: Csaba Nagy
• Re: planner with index scan cost way off actual cost,
  • From: Scott Marlowe
• Re: Massive Inserts Strategies
  • From: Jim C. Nasby
• Re: Massive Inserts Strategies
  • From: PFC
• Massive Inserts Strategies
  • From: ashah
• Re: WAL logging of SELECT ... INTO command
  • From: Tom Lane
• Re: WAL logging of SELECT ... INTO command
  • From: Jim C. Nasby
• Re: WAL logging of SELECT ... INTO command
  • From: Tom Lane
• Re: Migration study, step 1: bulk write performanceoptimization
  • From: Tom Lane
• Intel C/C++ Compiler Tests
  • From: Spiegelberg, Greg
• Re: WAL logging of SELECT ... INTO command
  • From: Jim C. Nasby
• Re: Migration study, step 1: bulk write performanceoptimization
  • From: Mikael Carneholm
• Re: WAL logging of SELECT ... INTO command
  • From: Simon Riggs
• Re: Migration study, step 1: bulk write performanceoptimization
  • From: Jim C. Nasby
• Re: WAL logging of SELECT ... INTO command
  • From: Jim C. Nasby
• Re: Poor performance o
  • From: Jim C. Nasby
• Re: Sequence Scan vs. Index scan
  • From: Alejandro D. Burne
• Re: Sequence Scan vs. Index scan
  • From: Steinar H. Gunderson
• Re: Sequence Scan vs. Index scan
  • From: Alejandro D. Burne
• Re: Migration study, step 1: bulk write
  • From: Simon Riggs
• Re: Query Feromance
  • From: Marco Furetto
• Re: Migration study, step 1: bulk write performanceoptimization
  • From: Mikael Carneholm
• Re: planner with index scan cost way off actual cost,
  • From: Guillaume Cottenceau
• Re: Poor performance o
  • From: Tom Lane
• motherboard recommendations
  • From: Jeff Frost
• Re: Best OS & Configuration for Dual Xeon w/4GB &
  • From: Vivek Khera
• Re: Poor performance o
  • From: Craig A. James
• Re: Poor performance o
  • From: Tom Lane
• Poor performance o
  • From: Craig A. James
• Re: Migration study, step 1: bulk write performance
  • From: Scott Marlowe
• Re: Migration study, step 1: bulk write performance
  • From: Tom Lane
• Re: Migration study, step 1: bulk write performance
  • From: Alvaro Herrera
• Re: Migration study, step 1: bulk write performance
  • From: Scott Marlowe
• Re: Migration study, step 1: bulk write performance
  • From: Ron
• Re: planner with index scan cost way off actual cost,
  • From: Simon Riggs
• Re: Migration study, step 1: bulk write performance
  • From: Simon Riggs
• Re: WAL logging of SELECT ... INTO command
  • From: Simon Riggs
• Re: Best OS & Configuration for Dual Xeon w/4GB & Adaptec
  • From: Vivek Khera
• Re: qsort again (was Re: Strange Create Index behaviour)
  • From: Tom Lane
• Re: Best OS & Configuration for Dual Xeon w/4GB &
  • From: Jeff Frost
• Re: Best OS & Configuration for Dual Xeon w/4GB &
  • From: Mark Kirkwood
• Re: Best OS & Configuration for Dual Xeon w/4GB & Adaptec
  • From: PFC
• Re: Sequence Scan vs. Index scan
  • From: Reimer
• Re: Sequence Scan vs. Index scan
  • From: Mikael Carneholm
• Re: Sequence Scan vs. Index scan
  • From: Steinar H. Gunderson
• Sequence Scan vs. Index scan
  • From: Fernando Lujan
• Re: Best OS & Configuration for Dual Xeon w/4GB &
  • From: Jim C. Nasby
• Re: planner with index scan cost way off actual cost,
  • From: Jim C. Nasby
• Re: planner with index scan cost way off actual cost, advices to tweak cost constants?
  • From: Jim C. Nasby
• Re: Postmaster using only 4-5% CPU
  • From: Scott Marlowe
• Re: update == delete + insert?
  • From: Jim C. Nasby
• Re: PostgreSQL and Xeon MP
  • From: Guillaume Smet
• Re: Best OS & Configuration for Dual Xeon w/4GB &
  • From: Adam Witney
• Re: Best OS & Configuration for Dual Xeon w/4GB & Adaptec
  • From: Vivek Khera
• Re: Best OS & Configuration for Dual Xeon w/4GB & Adaptec
  • From: Vivek Khera
• Re: Best OS & Configuration for Dual Xeon w/4GB &
  • From: Luke Lonergan
• Re: Postmaster using only 4-5% CPU
  • From: Guillaume Cottenceau