Архив рассылок [pgsql-performance]
Re: Query using SeqScan instead of IndexScan Jim C. Nasby
Re: Query using SeqScan instead of IndexScan Brendan Duddridge
Re: [Solved] Slow performance on Windows .NET and OleDb Merlin Moncure
Re: Query using SeqScan instead of IndexScan chris smith
Re: Query using SeqScan instead of IndexScan chris smith
Re: Query using SeqScan instead of IndexScan Alvaro Herrera
Re: Query using SeqScan instead of IndexScan Mark Kirkwood
Trigger vs Rule Ключников А.С.
Re: statistics buffer is full Qingqing Zhou
Re: Large Binary Objects Middleware Qingqing Zhou
Re: Logging SQL queries to optimize them ? Qingqing Zhou
Re: index not used again Jan Kesten
Re: index not used again Stephan Szabo
Re: Trigger vs Rule Niklas Johansson
Re: Query using SeqScan instead of IndexScan Josh Berkus
Re: Query using SeqScan instead of IndexScan Brendan Duddridge
Re: Trigger vs Rule Niklas Johansson
Re: Trigger vs Rule Ключников А.С.
optimizing db for small table with tons of updates Kenji Morishige
Re: optimizing db for small table with tons of updates Rajesh Kumar Mallah
Re: optimizing db for small table with tons of updates Kenji Morishige
Re: optimizing db for small table with tons of updates Alvaro Herrera
Re: optimizing db for small table with tons of updates Kenji Morishige
Re: optimizing db for small table with tons of updates Kenji Morishige
bad performance on Solaris 10 Chris Mair
Re: bad performance on Solaris 10 Josh Berkus
Re: freebsd/softupdates for data dir Mark Kirkwood
Re: bad performance on Solaris 10 Luke Lonergan
Re: bad performance on Solaris 10 Mark Kirkwood
Re: bad performance on Solaris 10 Josh Berkus
Re: freebsd/softupdates for data dir Vivek Khera
Re: vacuum full seems to hang on very small table Brad Nicholson
Re: Query runs too long for indexed tables Scott Marlowe
Re: Query runs too long for indexed tables Marc Morin
Re: Query runs too long for indexed tables Marc Morin
Sun Fire T2000 and PostgreSQL 8.1.3 Juan Casero \(FL FLC\)
Re: Sun Fire T2000 and PostgreSQL 8.1.3 Luke Lonergan
Re: Sun Fire T2000 and PostgreSQL 8.1.3 Juan Casero \(FL FLC\)
Re: bad performance on Solaris 10 Chris Mair
Re: Sun Fire T2000 and PostgreSQL 8.1.3 Luke Lonergan
Re: bad performance on Solaris 10 Luke Lonergan
Re: Sun Fire T2000 and PostgreSQL 8.1.3 Juan Casero \(FL FLC\)
Re: bad performance on Solaris 10 Alvaro Herrera
Re: Sun Fire T2000 and PostgreSQL 8.1.3 Luke Lonergan
Re: bad performance on Solaris 10 Luke Lonergan
Re: Sun Fire T2000 and PostgreSQL 8.1.3 August Zajonc
Re: Sun Fire T2000 and PostgreSQL 8.1.3 Josh Berkus
Re: freebsd/softupdates for data dir Jim Nasby
Re: Sun Fire T2000 and PostgreSQL 8.1.3 Scott Marlowe
Re: Sun Fire T2000 and PostgreSQL 8.1.3 Chris Browne
Re: Sun Fire T2000 and PostgreSQL 8.1.3 Chris Browne
Re: bad performance on Solaris 10 Chris Mair
Re: bad performance on Solaris 10 Mark Kirkwood
Re: bad performance on Solaris 10 Chris Mair
Re: bad performance on Solaris 10 Chris Mair
Re: Sun Fire T2000 and PostgreSQL 8.1.3 Juan Casero \(FL FLC\)
Re: Sun Fire T2000 and PostgreSQL 8.1.3 Luke Lonergan
Re: Sun Fire T2000 and PostgreSQL 8.1.3 Marcelo Tada
Re: bad performance on Solaris 10 Mark Kirkwood
Re: Sun Fire T2000 and PostgreSQL 8.1.3 Anthony Ransley
Re: Sun Fire T2000 and PostgreSQL 8.1.3 Robert Lor
Re: Sun Fire T2000 and PostgreSQL 8.1.3 Robert Lor
Re: Sun Fire T2000 and PostgreSQL 8.1.3 Leigh Dyer
Re: Sun Fire T2000 and PostgreSQL 8.1.3 Luke Lonergan
Re: Sun Fire T2000 and PostgreSQL 8.1.3 Leigh Dyer
Re: bad performance on Solaris 10 Chris Mair
Re: Sun Fire T2000 and PostgreSQL 8.1.3 Juan Casero \(FL FLC\)
Re: bad performance on Solaris 10 Josh Berkus
Re: bad performance on Solaris 10 Josh Berkus
Re: Sun Fire T2000 and PostgreSQL 8.1.3 Mark Kirkwood
Re: Sun Fire T2000 and PostgreSQL 8.1.3 Josh Berkus
Re: bad performance on Solaris 10 Robert Lor
Re: Sun Fire T2000 and PostgreSQL 8.1.3 Leigh Dyer
Query planner is using wrong index. Brian Herlihy
Re: Sun Fire T2000 and PostgreSQL 8.1.3 Markus Schaber
Re: Query planner is using wrong index. Brian Herlihy
Re: Sun Fire T2000 and PostgreSQL 8.1.3 Juan Casero \(FL FLC\)
Re: Intel C/C++ Compiler Tests (fwd) Bruce Momjian
Re: freebsd/softupdates for data dir Vivek Khera
Re: Sun Fire T2000 and PostgreSQL 8.1.3 Matthew Nuzum
Re: Query planner is using wrong index. Brian Herlihy
CURSOR OR OFFSET/LIMIT Kaloyan Iliev
Re: Sun Fire T2000 and PostgreSQL 8.1.3 Vivek Khera
Re: Sun Fire T2000 and PostgreSQL 8.1.3 Vivek Khera
Re: Sun Fire T2000 and PostgreSQL 8.1.3 Vivek Khera
Re: Sun Fire T2000 and PostgreSQL 8.1.3 Luke Lonergan
Re: CURSOR OR OFFSET/LIMIT John DeSoi
Re: Sun Fire T2000 and PostgreSQL 8.1.3 Jignesh K. Shah
Re: Sun Fire T2000 and PostgreSQL 8.1.3 Jignesh K. Shah
Re: Query planner is using wrong index. Brian Herlihy
Re: Query planner is using wrong index. Dave Dutcher
Re: Query planner is using wrong index. Brian Herlihy
Re: Query planner is using wrong index. Brian Herlihy
Same SQL, 104296ms of difference between 7.4.12 and 8.0.7 Rafael Martinez Guerrero
Re: Same SQL, 104296ms of difference between 7.4.12 and Richard Huxton
Re: Same SQL, 104296ms of difference between 7.4.12 and Rafael Martinez Guerrero
Loading the entire DB into RAM Charles A. Landemaine
Re: Same SQL, 104296ms of difference between 7.4.12 and Richard Huxton
Re: Same SQL, 104296ms of difference between 7.4.12 and Rafael Martinez
Re: Loading the entire DB into RAM Charles A. Landemaine
Re: Loading the entire DB into RAM Matt Davies | Postgresql List
Re: Spotting planner errors (was Re: Query planner is using Richard Huxton
Re: Loading the entire DB into RAM Tom Lane
Re: Loading the entire DB into RAM Merlin Moncure
Re: Loading the entire DB into RAM Scott Marlowe
pg 8.1.3, AIX, huge box, painfully slow. Gavin Hamill
Re: pg 8.1.3, AIX, huge box, painfully slow. Scott Marlowe
Re: Same SQL, 104296ms of difference between 7.4.12 and Rafael Martinez
Re: bad performance on Solaris 10 Chris Mair
Re: pg 8.1.3, AIX, huge box, painfully slow. Gavin Hamill
Re: pg 8.1.3, AIX, huge box, painfully slow. Gavin Hamill
Re: pg 8.1.3, AIX, huge box, painfully slow. D'Arcy J.M. Cain
Re: pg 8.1.3, AIX, huge box, painfully slow. Scott Marlowe
Re: pg 8.1.3, AIX, huge box, painfully slow. Greg Stark
Re: pg 8.1.3, AIX, huge box, painfully slow. Gábriel Ákos
Re: pg 8.1.3, AIX, huge box, painfully slow. Gavin Hamill
Re: pg 8.1.3, AIX, huge box, painfully slow. Gavin Hamill
Re: pg 8.1.3, AIX, huge box, painfully slow. Gavin Hamill
Re: pg 8.1.3, AIX, huge box, painfully slow. Luke Lonergan
Re: pg 8.1.3, AIX, huge box, painfully slow. Luke Lonergan
Re: pg 8.1.3, AIX, huge box, painfully slow. Gavin Hamill
Re: pg 8.1.3, AIX, huge box, painfully slow. Luke Lonergan
Re: pg 8.1.3, AIX, huge box, painfully slow. Gavin Hamill
Re: pg 8.1.3, AIX, huge box, painfully slow. Gavin Hamill
Re: Indexes with descending date columns Bruce Momjian
OT: Data structure design question: How do they count so fast? Brendan Duddridge
pls reply ASAP Chethana, Rao (IE10)
Re: Luckys
Re: Ragnar
Re: pls reply ASAP Rajesh Kumar Mallah
serious problems with vacuuming databases Tomas Vondra
Re: serious problems with vacuuming databases Alvaro Herrera
Re: Scaling up PostgreSQL in Multiple CPU / Dual Core Bruce Momjian
Re: serious problems with vacuuming databases Tomas Vondra
Re: serious problems with vacuuming databases Tomas Vondra
Re: serious problems with vacuuming databases Tomas Vondra
Re: serious problems with vacuuming databases Alvaro Herrera
Re: serious problems with vacuuming databases Tomas Vondra
Re: serious problems with vacuuming databases Alvaro Herrera
Re: slow "IN" clause Qingqing Zhou
Re: OT: Data structure design question: How do they count so fast? Brendan Duddridge
Re: serious problems with vacuuming databases Ahmad Fajar
Re: Doron Baranes
Restore performance? Jesper Krogh
Re: Restore performance? Luke Lonergan
Dump restore performance 7.3 -> 8.1 Jesper Krogh
Re: Restore performance? Andreas Pflug
Re: Restore performance? Jesper Krogh
Re: Restore performance? Marcin Mańk
Re: pg 8.1.3, AIX, huge box, painfully slow. Richard Huxton
Re: OT: Data structure design question: How do they count Richard Huxton
Re: pg 8.1.3, AIX, huge box, painfully slow. Simon Riggs
Re: pg 8.1.3, AIX, huge box, painfully slow. Gavin Hamill
Re: Ragnar
Re: Restore performance? Tom Lane
Re: Restore performance? Rajesh Kumar Mallah
Re: Restore performance? Rajesh Kumar Mallah
Re: Restore performance? Jesper Krogh
Re: Takes too long to fetch the data from database Rajesh Kumar Mallah
Re: Restore performance? Rajesh Kumar Mallah
Re: Restore performance? Alvaro Herrera
Better index stategy for many fields with few values Oscar Picasso
Re: Takes too long to fetch the data from database Joshua D. Drake
Re: Restore performance? Vivek Khera
Encouraging multi-table join order Dan Harris
Re: pg 8.1.3, AIX, huge box, painfully slow. Brad Nicholson
Re: OT: Data structure design question: How do they count so fast? Brendan Duddridge
Re: bad performance on Solaris 10 Chris Mair
Re: Encouraging multi-table join order Dan Harris
pgmemcache C Storm
slow "IN" clause FavoYang@gmail.com
Re: slow "IN" clause Vinko Vrsalovic
Stored Procedure Performance Simon Dale
Re: Stored Procedure Performance hubert depesz lubaczewski
Re: Stored Procedure Performance Rajesh Kumar Mallah
Re: Stored Procedure Performance Richard Huxton
Re: Takes too long to fetch the data from database Richard Huxton
Re: Restore performance? Jesper Krogh
Re: Takes too long to fetch the data from database Merlin Moncure
Re: Stored Procedure Performance Merlin Moncure
Re: Stored Procedure Performance Christopher Browne
Re: Stored Procedure Performance H.J. Sanders
Re: Stored Procedure Performance Alvaro Herrera
Re: Indexes with descending date columns Markus Schaber
FOREIGN KEYS vs PERFORMANCE Rodrigo Sakai
Re: FOREIGN KEYS vs PERFORMANCE Scott Marlowe
Re: Encouraging multi-table join order Dan Harris
Re: Stored Procedure Performance Merlin Moncure
Re: Encouraging multi-table join order Dan Harris
Re: Sequencial scan instead of using index markir@paradise.net.nz
Re: Sequencial scan instead of using index markir@paradise.net.nz
Re: Sequencial scan instead of using index Harry Hehl
Re: pgmemcache Jim C. Nasby
Re: freebsd/softupdates for data dir Jim C. Nasby
Re: FOREIGN KEYS vs PERFORMANCE Michael Glaesemann
Re: FOREIGN KEYS vs PERFORMANCE Jim C. Nasby
Re: Restore performance? Christopher Kings-Lynne
Re: FOREIGN KEYS vs PERFORMANCE Tom Lane
Re: pgmemcache PFC
Re: Better index stategy for many fields with few values Markus Schaber
Re: Sequencial scan instead of using index Harry Hehl
Re: FOREIGN KEYS vs PERFORMANCE Markus Schaber
Re: FOREIGN KEYS vs PERFORMANCE Craig A. James
Re: FOREIGN KEYS vs PERFORMANCE Rodrigo Sakai
Re: FOREIGN KEYS vs PERFORMANCE Merlin Moncure
Re: FOREIGN KEYS vs PERFORMANCE Michael Glaesemann
Re: FOREIGN KEYS vs PERFORMANCE Scott Marlowe
Re: FOREIGN KEYS vs PERFORMANCE Jim C. Nasby
Re: FOREIGN KEYS vs PERFORMANCE Jim C. Nasby
Re: FOREIGN KEYS vs PERFORMANCE Craig A. James
Re: bad performance on Solaris 10 Bruce Momjian
Re: FOREIGN KEYS vs PERFORMANCE Jim C. Nasby
Re: bad performance on Solaris 10 Luke Lonergan
Re: Better index stategy for many fields with few Luke Lonergan
Re: bad performance on Solaris 10 Josh Berkus
Re: pgmemcache Josh Berkus
Re: pgmemcache Jim C. Nasby
multi column query Sriram Dandapani
Re: pgmemcache Tom Lane
Re: multi column query Jim C. Nasby
Inserts optimization? Francisco Reyes
pg 7.4.x - pg_restore impossibly slow patrick keshishian
Re: FOREIGN KEYS vs PERFORMANCE Craig A. James
Re: bad performance on Solaris 10 Jignesh K. Shah
Re: Sun Fire T2000 and PostgreSQL 8.1.3 Bruce Momjian
Re: Inserts optimization? Tom Lane
Re: bad performance on Solaris 10 Tom Lane
Re: bad performance on Solaris 10 Bruce Momjian
Re: Better index stategy for many fields with few values Markus Schaber
Re: Better index stategy for many fields with few values Markus Schaber
Slow query - possible bug? Gavin Hamill
Re: Slow query - possible bug? chris smith
Re: Slow query - possible bug? Gavin Hamill
Re: Slow query - possible bug? Richard Huxton
Re: Better index stategy for many fields with few values Markus Schaber
Re: pgmemcache Markus Schaber
Re: pg 8.1.3, AIX, huge box, painfully slow. Gavin Hamill
Re: Slow query - possible bug? Tom Lane
Re: Better index stategy for many fields with few values Oscar Picasso
Re: multi column query Jim Nasby
Re: pgmemcache Tom Lane
Re: bad performance on Solaris 10 Robert Lor
Blocks read for index scans Jim Nasby
Re: pgmemcache Jim Nasby
Re: Inserts optimization? Francisco Reyes
Re: Blocks read for index scans Jim Nasby
Re: Inserts optimization? Francisco Reyes
Re: bad performance on Solaris 10 Merlin Moncure
Re: multi column query Sriram Dandapani
Re: pgmemcache PFC
Re: pgmemcache Greg Stark
Re: Blocks read for index scans Tom Lane
Re: pgmemcache Tom Lane
Re: pg 7.4.x - pg_restore impossibly slow patrick keshishian
Re: Inserts optimization? Jim C. Nasby
Re: Blocks read for index scans Jim C. Nasby
Re: pg 7.4.x - pg_restore impossibly slow Jim C. Nasby
Re: Blocks read for index scans Terje Elde
Re: pg 7.4.x - pg_restore impossibly slow patrick keshishian
Re: pg 7.4.x - pg_restore impossibly slow patrick keshishian
Re: Inserts optimization? Francisco Reyes
Re: Inserts optimization? Michael Stone
Re: Inserts optimization? Marc Cousin
pg_toast size Julien Drouard
Re: bad performance on Solaris 10 Jignesh K. Shah
Re: Blocks read for index scans Tom Lane
merge>hash>loop Ian Westmacott
Re: Inserts optimization? Francisco Reyes
Re: merge>hash>loop Tom Lane
Re: Inserts optimization? Tom Lane
Re: merge>hash>loop Ian Westmacott
Re: merge>hash>loop Tom Lane
Re: Inserts optimization? Francisco Reyes
Re: Inserts optimization? Francisco Reyes
Re: bad performance on Solaris 10 Josh Berkus
Re: Inserts optimization? Michael Stone
Re: Inserts optimization? Francisco Reyes
Re: Inserts optimization? Scott Marlowe
Re: Inserts optimization? Francisco Reyes
Re: Inserts optimization? Gábriel Ákos
Re: Inserts optimization? Gábriel Ákos
Re: Inserts optimization? Francisco Reyes
Re: Inserts optimization? Francisco Reyes
Re: Inserts optimization? Francisco Reyes
Migration study, step 2: rewriting queries Mikael Carneholm
Re: pgmemcache Christian Storm
Re: pgmemcache Christian Storm
slow cursor Sriram Dandapani
creating of temporary table takes very long Sriram Dandapani
Re: creating of temporary table takes very long Sriram Dandapani
Re: creating of temporary table takes very long Sriram Dandapani
Re: creating of temporary table takes very long Sriram Dandapani
Re: slow cursor Luckys
Re: Slow query - possible bug? Gavin Hamill
Re: Migration study, step 2: rewriting queries Mikael Carneholm
Re: Inserts optimization? Markus Schaber
Re: merge>hash>loop Markus Schaber
Re: Inserts optimization? Magnus Hagander
SELECT FOR UPDATE performance is bad Mario Splivalo
Problem with LIKE-Performance Tarabas (Manuel Rorarius)
Re: Problem with LIKE-Performance Dave Dutcher
Re: Problem with LIKE-Performance Tarabas (Manuel Rorarius)
Re: Problem with LIKE-Performance Tom Lane
Re: Problem with LIKE-Performance Tarabas (Manuel Rorarius)
Re: Problem with LIKE-Performance Hakan Kocaman
Re: Problem with LIKE-Performance REISS Thomas DSIC DESP
Re: Problem with LIKE-Performance Guido Neitzer
Re: [bulk] RE: Problem with LIKE-Performance Tarabas (Manuel Rorarius)
Re: Problem with LIKE-Performance Tom Lane
Re: [bulk] Re: Problem with LIKE-Performance Tarabas (Manuel Rorarius)
Re: creating of temporary table takes very long Sriram Dandapani
Re: [bulk] Re: Problem with LIKE-Performance Richard Huxton
Re: [bulk] Re: [bulk] Re: Problem with LIKE-Performance Tarabas (Manuel Rorarius)
Re: FOREIGN KEYS vs PERFORMANCE Rodrigo Sakai
Re: Slow query - possible bug? Tom Lane
Re: Slow query - possible bug? Gavin Hamill
Re: Slow query - possible bug? Tom Lane
Re: Blocks read for index scans Jim C. Nasby
Re: Blocks read for index scans Jim C. Nasby
Re: Slow query - possible bug? Gavin Hamill
Re: Inserts optimization? Jim C. Nasby
Re: Inserts optimization? Jim C. Nasby
Re: pg_toast size Jim C. Nasby
Re: merge>hash>loop Jim C. Nasby
Re: merge>hash>loop Tom Lane
Re: merge>hash>loop Tom Lane
Re: creating of temporary table takes very long Jim C. Nasby
Multicolumn order by Theo Kramer
Re: Multicolumn order by Tom Lane
Re: Multicolumn order by Jim C. Nasby
Re: merge>hash>loop Jim C. Nasby
Re: merge>hash>loop Jim C. Nasby
Re: merge>hash>loop Tom Lane
Planner doesn't chose Index - (slow select) patrick keshishian
Re: SELECT FOR UPDATE performance is bad Christopher Kings-Lynne
Re: Blocks read for index scans Terje Elde
Re: merge>hash>loop Mark Kirkwood
Re: Blocks read for index scans Jim C. Nasby
Re: merge>hash>loop Jim C. Nasby
Re: merge>hash>loop Tom Lane
Re: Blocks read for index scans Mark Kirkwood
Re: merge>hash>loop Mark Kirkwood
Re: Multicolumn order by Theo Kramer
Re: SELECT FOR UPDATE performance is bad Mario Splivalo
Re: SELECT FOR UPDATE performance is bad Mario Splivalo
Re: Multicolumn order by Theo Kramer
Re: Inserts optimization? Markus Schaber
Re: Inserts optimization? Magnus Hagander
Re: Inserts optimization? Markus Schaber
Re: Inserts optimization? Tom Lane
Re: Inserts optimization? Scott Marlowe
Re: Inserts optimization? Tom Lane
Re: Inserts optimization? Scott Marlowe
Re: Planner doesn't chose Index - (slow select) patrick keshishian
Re: Inserts optimization? Christopher Kings-Lynne
Re: Inserts optimization? Mark Kirkwood
Re: Takes too long to fetch the data from database Bruno Wolff III
Perfrmance Problems (7.4.6) Doron Baranes
Re: Perfrmance Problems (7.4.6) Ruben Rubio Rey
Re: Perfrmance Problems (7.4.6) Doron Baranes
Quick Performance Poll Simon Dale
Re: Quick Performance Poll Jim Buttafuoco
Identical query on two machines, different plans.... Mario Splivalo
Re: Identical query on two machines, different plans.... Mario Splivalo
Re: Inserts optimization? Scott Marlowe
Re: Quick Performance Poll Luke Lonergan
Re: Quick Performance Poll Jim Buttafuoco
Re: Perfrmance Problems (7.4.6) Ruben Rubio Rey
Re: Quick Performance Poll Luke Lonergan
Re: Quick Performance Poll Jim Buttafuoco
Re: Quick Performance Poll Markus Schaber
IBM pSeries - overrated bucket of crud? Gavin Hamill
Re: Quick Performance Poll Luke Lonergan
Performance decrease Radovan Antloga
Re: Performance decrease Tom Lane
Re: Takes too long to fetch the data from database Merlin Moncure
Re: Performance decrease Radovan Antloga
Re: merge>hash>loop Jim C. Nasby
Re: SELECT FOR UPDATE performance is bad Jim C. Nasby
Re: Quick Performance Poll Jim C. Nasby
Re: Performance decrease Jim C. Nasby
Hardware: HP StorageWorks MSA 1500 Mikael Carneholm
Re: Hardware: HP StorageWorks MSA 1500 Mark Lewis
Recovery will take 10 hours Brendan Duddridge
Re: Inserts optimization? Vivek Khera
Re: Inserts optimization? Vivek Khera
Re: Quick Performance Poll Milen Kulev
Re: Recovery will take 10 hours Tom Lane
Re: Recovery will take 10 hours Brendan Duddridge
Re: Performance decrease Guido Neitzer
Re: Recovery will take 10 hours Tom Lane
Re: Recovery will take 10 hours Luke Lonergan
Re: Quick Performance Poll Luke Lonergan
Re: Recovery will take 10 hours Jeff Frost
Re: Recovery will take 10 hours Brendan Duddridge
Re: Recovery will take 10 hours Brendan Duddridge
Re: Recovery will take 10 hours Brendan Duddridge
Re: Recovery will take 10 hours Tom Lane
Re: Recovery will take 10 hours Jeff Frost
Re: Recovery will take 10 hours Brendan Duddridge
Re: Recovery will take 10 hours Tom Lane
Re: Recovery will take 10 hours Brendan Duddridge
Re: Recovery will take 10 hours Brendan Duddridge
Re: Recovery will take 10 hours Brendan Duddridge
Re: Recovery will take 10 hours Gavin Sherry
Introducing a new linux readahead framework Wu Fengguang
Re: Introducing a new linux readahead framework Jim C. Nasby
Re: Quick Performance Poll Milen Kulev
Re: Introducing a new linux readahead framework Wu Fengguang
Re: Introducing a new linux readahead framework Markus Schaber
Better way to write aggregates? Jan Dittmer
Little use of CPU ( < 5%) luchot
Re: Introducing a new linux readahead framework Wu Fengguang
Re: Better way to write aggregates? Jim Buttafuoco
Re: Better way to write aggregates? Jan Dittmer
Re: Better way to write aggregates? Jim Buttafuoco
Re: Takes too long to fetch the data from database Dave Dutcher
Re: Takes too long to fetch the data from database Merlin Moncure
Re: Little use of CPU ( < 5%) Dave Dutcher
Re: Better way to write aggregates? Tom Lane
Re: Hardware: HP StorageWorks MSA 1500 Alex Hayward
Inactive memory Grows unlimited ALVARO ARCILA
Re: Inactive memory Grows unlimited Alvaro Herrera
Re: Takes too long to fetch the data from database Bruno Wolff III
Re: Takes too long to fetch the data from database Jim C. Nasby
Re: Introducing a new linux readahead framework Jim C. Nasby
Re: Hardware: HP StorageWorks MSA 1500 Mikael Carneholm
Re: WAL logging of SELECT ... INTO command Bruce Momjian
Re: WAL logging of SELECT ... INTO command Simon Riggs
Re: Introducing a new linux readahead framework Wu Fengguang
Re: Recovery will take 10 hours Simon Riggs
GROUP BY Vs. Sub SELECT Bruno Almeida do Lago
Re: GROUP BY Vs. Sub SELECT Tom Lane
Re: Hardware: HP StorageWorks MSA 1500 Mark Kirkwood
Slow deletes in 8.1 when FKs are involved Will Reese
Re: Recovery will take 10 hours Brendan Duddridge
Re: Inactive memory Grows unlimited Matteo Beccati
Re: Recovery will take 10 hours Markus Schaber
Re: Recovery will take 10 hours Simon Riggs
Re: Slow deletes in 8.1 when FKs are involved Jim C. Nasby
Re: GROUP BY Vs. Sub SELECT Bruno Almeida do Lago
Re: Hardware: HP StorageWorks MSA 1500 Alex Hayward
Re: GROUP BY Vs. Sub SELECT Richard Broersma Jr
Re: Hardware: HP StorageWorks MSA 1500 Mikael Carneholm
Re: GROUP BY Vs. Sub SELECT Jim C. Nasby
ip address data type Sriram Dandapani
Re: ip address data type Jim C. Nasby
Re: ip address data type Steve Atkins
Re: Hardware: HP StorageWorks MSA 1500 Mark Kirkwood
Introducing a new linux readahead framework Wu Fengguang
Slow deletes in 8.1 when FKs are involved Will Reese
Easy question clemens.bertschler@gmail.com
Re: serious problems with vacuuming databases Tomas Vondra
Re: security for row level but not based on Database user's Richard Huxton
Re: security for row level but not based on Database user's Richard Huxton
Re: Query on postgresql 7.4.2 not using index chris smith
Re: Query on postgresql 7.4.2 not using index Guillaume Smet
Re: Query on postgresql 7.4.2 not using index Scott Marlowe
Re: Query on postgresql 7.4.2 not using index Scott Marlowe
PL/pgSQL Loop Vs. Batch Update David Wheeler
planner not using index for like operator Sriram Dandapani
Re: planner not using index for like operator Dave Dutcher
Large (8M) cache vs. dual-core CPUs Bill Moran
Re: Slow queries salad ;) Tom Lane
Re: planner not using index for like operator Jim C. Nasby
Re: planner not using index for like operator Sriram Dandapani
Re: Large (8M) cache vs. dual-core CPUs Scott Marlowe
Re: Large (8M) cache vs. dual-core CPUs Gavin Hamill
Re: Slow queries salad ;) Jim C. Nasby
Re: Large (8M) cache vs. dual-core CPUs Scott Marlowe
Re: Large (8M) cache vs. dual-core CPUs mark@mark.mielke.cc
Re: Large (8M) cache vs. dual-core CPUs Scott Marlowe
Re: Large (8M) cache vs. dual-core CPUs Joshua D. Drake
Re: planner not using index for like operator Sriram Dandapani
Re: Large (8M) cache vs. dual-core CPUs Joshua D. Drake
Re: ip address data type Florian Weimer
Re: Large (8M) cache vs. dual-core CPUs David Boreham
Re: Large (8M) cache vs. dual-core CPUs Joshua D. Drake
Re: Large (8M) cache vs. dual-core CPUs Bruce Momjian
Re: Large (8M) cache vs. dual-core CPUs Ron Peacetree
Re: Large (8M) cache vs. dual-core CPUs David Boreham
slow deletes on pgsql 7.4 Junaili Lie
Re: Large (8M) cache vs. dual-core CPUs Ron Peacetree
Re: slow deletes on pgsql 7.4 Junaili Lie
Re: Large (8M) cache vs. dual-core CPUs Joshua D. Drake
Re: slow deletes on pgsql 7.4 Tom Lane
Re: Large (8M) cache vs. dual-core CPUs Jim C. Nasby
Re: slow deletes on pgsql 7.4 Junaili Lie
Re: Large (8M) cache vs. dual-core CPUs mark@mark.mielke.cc
Re: slow deletes on pgsql 7.4 Tom Lane
Re: Large (8M) cache vs. dual-core CPUs mark@mark.mielke.cc
Re: PL/pgSQL Loop Vs. Batch Update Tom Lane
Re: Query on postgresql 7.4.2 not using index chris smith
Re: Large (8M) cache vs. dual-core CPUs Leigh Dyer
Re: PL/pgSQL Loop Vs. Batch Update David Wheeler
Re: PL/pgSQL Loop Vs. Batch Update Tom Lane
Re: Large (8M) cache vs. dual-core CPUs Ron Peacetree
Re: PL/pgSQL Loop Vs. Batch Update David Wheeler
Re: Large (8M) cache vs. dual-core CPUs mark@mark.mielke.cc
Re: Large (8M) cache vs. dual-core CPUs Ron Peacetree
Re: Large (8M) cache vs. dual-core CPUs David Boreham
Re: Large (8M) cache vs. dual-core CPUs William Yu
Re: slow deletes on pgsql 7.4 Junaili Lie
Re: Large (8M) cache vs. dual-core CPUs David Boreham
Re: Introducing a new linux readahead framework Michael Stone
Re: Large (8M) cache vs. dual-core CPUs Ron Peacetree
Re: Large (8M) cache vs. dual-core CPUs Scott Marlowe
Re: Large (8M) cache vs. dual-core CPUs William Yu
Re: Large (8M) cache vs. dual-core CPUs Scott Marlowe
Re: Large (8M) cache vs. dual-core CPUs Jim C. Nasby
Re: Large (8M) cache vs. dual-core CPUs Jim C. Nasby
Re: Large (8M) cache vs. dual-core CPUs Jim C. Nasby
Re: Large (8M) cache vs. dual-core CPUs Bruce Momjian
Re: Large (8M) cache vs. dual-core CPUs Jim C. Nasby
Re: Introducing a new linux readahead framework Jim C. Nasby
Re: Large (8M) cache vs. dual-core CPUs Jim C. Nasby
Re: WAL logging of SELECT ... INTO command Bruce Momjian
Re: [Bizgres-general] Introducing a new linux Luke Lonergan
Re: [Bizgres-general] Introducing a new linux Michael Stone
Running on an NFS Mounted Directory Ketema Harris
Re: Large (8M) cache vs. dual-core CPUs mark@mark.mielke.cc
Re: Running on an NFS Mounted Directory Steve Wampler
Re: Running on an NFS Mounted Directory Jim C. Nasby
Re: Running on an NFS Mounted Directory Dan Gorman
Re: Introducing a new linux readahead framework Michael Stone
Firebird 1.5.3 X Postgresql 8.1.3 (linux Firebird 1.5.3 X Postgresql 8.1.3 (linux and and windows)] andremachado
Re: Running on an NFS Mounted Directory Ketema Harris
Re: Running on an NFS Mounted Directory Michael Stone
Re: Running on an NFS Mounted Directory Ketema Harris
Re: Running on an NFS Mounted Directory Bruno Wolff III
Re: Running on an NFS Mounted Directory Ketema Harris
Re: Running on an NFS Mounted Directory Steve Wampler
Re: Running on an NFS Mounted Directory Michael Stone
Re: Running on an NFS Mounted Directory Bruno Wolff III
Re: Running on an NFS Mounted Directory Ketema Harris
Re: Running on an NFS Mounted Directory Ketema Harris
Re: Running on an NFS Mounted Directory Michael Stone
Re: Hardware: HP StorageWorks MSA 1500 Alex Hayward
Re: Large (8M) cache vs. dual-core CPUs Vivek Khera
Re: Large (8M) cache vs. dual-core CPUs Vivek Khera
Re: Running on an NFS Mounted Directory Jim C. Nasby
Re: Running on an NFS Mounted Directory Michael Stone
Why so slow? Bealach-na Bo
Re: Why so slow? Andreas Kretschmer
Re: Running on an NFS Mounted Directory Dan Gorman
Re: Hardware: HP StorageWorks MSA 1500 Mark Kirkwood
Re: how unsafe (or worst scenarios) when setting fsync Guoping Zhang
Re: Large (8M) cache vs. dual-core CPUs Sven Geisler
Re: how unsafe (or worst scenarios) when setting fsync Markus Schaber
query performance question gulsah
Re: Why so slow? Bealach-na Bo
Arrays and index scan Markus Schaber
Re: Why so slow? Jim C. Nasby
Re: Why so slow? Alan Hodgson
Re: Arrays and index scan Tom Lane
hardare config question Erik Myllymaki
Re: Why so slow? Bealach-na Bo
Re: hardare config question Vivek Khera
Re: Why so slow? Bealach-na Bo
Re: Why so slow? Alan Hodgson
Re: hardare config question Mark Lewis
Re: hardare config question Ron Peacetree
Re: Why so slow? Bruno Wolff III
Re: Why so slow? K C Lau
Re: Why so slow? Tom Lane
Re: Why so slow? K C Lau
Re: hardare config question Luke Lonergan
Re: Why so slow? Michael Stone
Re: Easy question codeWarrior
Re: Hardware: HP StorageWorks MSA 1500 mlartz@gmail.com
Slow restoration question Eric Lam
Re: Easy question Bert
Performance Issues on Opteron Dual Core Gregory Stewart
Re: Slow restoration question Tom Lane
Re: Slow restoration question Andreas Kretschmer
Re: Easy question Michael Artz
Re: Why so slow? Bealach-na Bo
Re: Performance Issues on Opteron Dual Core Mark Kirkwood
Re: Why so slow? Bill Moran
Re: query performance question Dave Dutcher
