Postgres Performance Date Index

• Thread Index

• Re: Super-smack?
  • From: Steve Woodcock
• Re: Super-smack?
  • From: Steinar H. Gunderson
• Re: Easy question
  • From: mlartz@xxxxxxxxx
• Super-smack?
  • From: Scott Sipe
• Re: query performance question
  • From: Dave Dutcher
• Re: Slow restoration question
  • From: Eric Lam
• Re: Why so slow?
  • From: Bill Moran
• Re: Performance Issues on Opteron Dual Core
  • From: Mark Kirkwood
• Re: Why so slow?
  • From: Bealach-na Bo
• Re: Easy question
  • From: Bert
• Re: Worsening performance with 7.4 on flash-based system
  • From: chris smith
• Re: Easy question
  • From: Michael Artz
• Re: Worsening performance with 7.4 on flash-based system
  • From: William Yu
• Re: Slow restoration question
  • From: Andreas Kretschmer
• Re: Slow restoration question
  • From: Tom Lane
• Re: Why so slow?
  • From: Michael Stone
• Re: hardare config question
  • From: Luke Lonergan
• Re: Why so slow?
  • From: K C Lau
• Re: Why so slow?
  • From: Tom Lane
• Re: Why so slow?
  • From: K C Lau
• Performance Issues on Opteron Dual Core
  • From: Gregory Stewart
• Re: Why so slow?
  • From: Bruno Wolff III
• Re: Worsening performance with 7.4 on flash-based system
  • From: Greg Stumph
• Re: hardare config question
  • From: Ron Peacetree
• Re: hardare config question
  • From: Mark Lewis
• Re: Why so slow?
  • From: Alan Hodgson
• Re: Why so slow?
  • From: Bealach-na Bo
• Re: hardare config question
  • From: Vivek Khera
• Re: Why so slow?
  • From: Bealach-na Bo
• Re: CPU usage goes to 100%, query seems to ran forever
  • From: Andrus
• hardare config question
  • From: Erik Myllymaki
• Re: Arrays and index scan
  • From: Tom Lane
• Re: Why so slow?
  • From: Alan Hodgson
• Re: Why so slow?
  • From: Jim C. Nasby
• Re: CPU usage goes to 100%, query seems to ran forever
  • From: Tom Lane
• Arrays and index scan
  • From: Markus Schaber
• Re: Why so slow?
  • From: Bealach-na Bo
• query performance question
  • From: gulsah
• Re: CPU usage goes to 100%, query seems to ran forever
  • From: Andrus
• Re: how unsafe (or worst scenarios) when setting fsync
  • From: Markus Schaber
• Re: how unsafe (or worst scenarios) when setting fsync OFF for postgresql
  • From: Mikael Carneholm
• Re: Large (8M) cache vs. dual-core CPUs
  • From: Sven Geisler
• Re: how unsafe (or worst scenarios) when setting fsync OFF for postgresql
  • From: Guoping Zhang
• Re: how unsafe (or worst scenarios) when setting fsync OFF for postgresql
  • From: Guoping Zhang
• Re: how unsafe (or worst scenarios) when setting fsync
  • From: Tom Lane
• Re: how unsafe (or worst scenarios) when setting fsync
  • From: Guoping Zhang
• Re: how unsafe (or worst scenarios) when setting fsync OFF for postgresql
  • From: Tom Lane
• Re: how unsafe (or worst scenarios) when setting fsync OFF for postgresql
  • From: Guoping Zhang
• Re: Hardware: HP StorageWorks MSA 1500
  • From: Mark Kirkwood
• Re: CPU usage goes to 100%, query seems to ran forever
  • From: Tom Lane
• Re: Running on an NFS Mounted Directory
  • From: Dan Gorman
• CPU usage goes to 100%, query seems to ran forever
  • From: Andrus
• Re: Why so slow?
  • From: Andreas Kretschmer
• Why so slow?
  • From: Bealach-na Bo
• Re: Running on an NFS Mounted Directory
  • From: Michael Stone
• Re: Running on an NFS Mounted Directory
  • From: Jim C. Nasby
• Re: Firebird 1.5.3 X Postgresql 8.1.3 (linux Firebird 1.5.3 X Postgresql 8.1.3 (linux and and windows)]
  • From: Tom Lane
• Re: Large (8M) cache vs. dual-core CPUs
  • From: Vivek Khera
• Re: Large (8M) cache vs. dual-core CPUs
  • From: Vivek Khera
• Re: how unsafe (or worst scenarios) when setting fsync
  • From: Tom Lane
• Re: how unsafe (or worst scenarios) when setting fsync OFF for postgresql
  • From: Tom Lane
• Re: Hardware: HP StorageWorks MSA 1500
  • From: Alex Hayward
• Re: Running on an NFS Mounted Directory
  • From: Michael Stone
• Re: Running on an NFS Mounted Directory
  • From: Ketema Harris
• Re: Running on an NFS Mounted Directory
  • From: Ketema Harris
• Re: Running on an NFS Mounted Directory
  • From: Bruno Wolff III
• Re: Running on an NFS Mounted Directory
  • From: Michael Stone
• Re: Running on an NFS Mounted Directory
  • From: Steve Wampler
• Re: Running on an NFS Mounted Directory
  • From: Ketema Harris
• Re: Running on an NFS Mounted Directory
  • From: Bruno Wolff III
• Re: Running on an NFS Mounted Directory
  • From: Ketema Harris
• Re: Running on an NFS Mounted Directory
  • From: Michael Stone
• Re: Running on an NFS Mounted Directory
  • From: Ketema Harris
• Firebird 1.5.3 X Postgresql 8.1.3 (linux Firebird 1.5.3 X Postgresql 8.1.3 (linux and and windows)]
  • From: andremachado
• Re: Introducing a new linux readahead framework
  • From: Michael Stone
• Re: how unsafe (or worst scenarios) when setting fsync OFF for postgresql
  • From: Guillaume Smet
• Re: how unsafe (or worst scenarios) when setting fsync OFF for postgresql
  • From: Mikael Carneholm
• Re: how unsafe (or worst scenarios) when setting fsync
  • From: Simon Riggs
• how unsafe (or worst scenarios) when setting fsync OFF for postgresql
  • From: Guoping Zhang
• Re: Running on an NFS Mounted Directory
  • From: Dan Gorman
• Re: Running on an NFS Mounted Directory
  • From: Jim C. Nasby
• Re: Running on an NFS Mounted Directory
  • From: Steve Wampler
• Re: Large (8M) cache vs. dual-core CPUs
  • From: mark
• Re: Slow deletes in 8.1 when FKs are involved
  • From: Will Reese
• Running on an NFS Mounted Directory
  • From: Ketema Harris
• Re: Easy question
  • From: Bert
• Re: [Bizgres-general] Introducing a new linux
  • From: Michael Stone
• Re: Slow deletes in 8.1 when FKs are involved
  • From: Stef T
• Re: [Bizgres-general] Introducing a new linux
  • From: Luke Lonergan
• Re: WAL logging of SELECT ... INTO command
  • From: Bruce Momjian
• Re: Large (8M) cache vs. dual-core CPUs
  • From: Jim C. Nasby
• Re: Introducing a new linux readahead framework
  • From: Jim C. Nasby
• Re: Large (8M) cache vs. dual-core CPUs
  • From: Jim C. Nasby
• Re: Large (8M) cache vs. dual-core CPUs
  • From: Bruce Momjian
• Re: Large (8M) cache vs. dual-core CPUs
  • From: Jim C. Nasby
• Re: Large (8M) cache vs. dual-core CPUs
  • From: Jim C. Nasby
• Re: Large (8M) cache vs. dual-core CPUs
  • From: Jim C. Nasby
• Re: Introducing a new linux readahead framework
  • From: Steve Poe
• Re: Large (8M) cache vs. dual-core CPUs
  • From: Scott Marlowe
• Re: Large (8M) cache vs. dual-core CPUs
  • From: William Yu
• Re: Large (8M) cache vs. dual-core CPUs
  • From: Scott Marlowe
• Re: Large (8M) cache vs. dual-core CPUs
  • From: PFC
• Re: Large (8M) cache vs. dual-core CPUs
  • From: Ron Peacetree
• Re: Introducing a new linux readahead framework
  • From: Michael Stone
• Re: Large (8M) cache vs. dual-core CPUs
  • From: David Boreham
• Re: slow deletes on pgsql 7.4
  • From: Junaili Lie
• Re: Large (8M) cache vs. dual-core CPUs
  • From: William Yu
• Re: Large (8M) cache vs. dual-core CPUs
  • From: David Boreham
• Re: Large (8M) cache vs. dual-core CPUs
  • From: Ron Peacetree
• Slow restoration question
  • From: Eric Lam
• Re: Large (8M) cache vs. dual-core CPUs
  • From: mark
• Re: PL/pgSQL Loop Vs. Batch Update
  • From: David Wheeler
• Re: Large (8M) cache vs. dual-core CPUs
  • From: Ron Peacetree
• Re: PL/pgSQL Loop Vs. Batch Update
  • From: Tom Lane
• Re: PL/pgSQL Loop Vs. Batch Update
  • From: David Wheeler
• Re: Large (8M) cache vs. dual-core CPUs
  • From: Leigh Dyer
• Re: Firebird 1.5.3 X Postgresql 8.1.3 (linux and windows)
  • From: Tom Lane
• Re: Hardware: HP StorageWorks MSA 1500
  • From: mlartz@xxxxxxxxx
• Re: Query on postgresql 7.4.2 not using index
  • From: chris smith
• Re: PL/pgSQL Loop Vs. Batch Update
  • From: Tom Lane
• Re: Large (8M) cache vs. dual-core CPUs
  • From: mark
• Re: slow deletes on pgsql 7.4
  • From: Tom Lane
• Re: Large (8M) cache vs. dual-core CPUs
  • From: mark
• Re: slow deletes on pgsql 7.4
  • From: Junaili Lie
• Re: Slow deletes in 8.1 when FKs are involved
  • From: Will Reese
• Re: Large (8M) cache vs. dual-core CPUs
  • From: Jim C. Nasby
• Re: slow deletes on pgsql 7.4
  • From: Tom Lane
• Re: Large (8M) cache vs. dual-core CPUs
  • From: Joshua D. Drake
• Re: slow deletes on pgsql 7.4
  • From: Junaili Lie
• Re: Large (8M) cache vs. dual-core CPUs
  • From: Ron Peacetree
• slow deletes on pgsql 7.4
  • From: Junaili Lie
• Re: Large (8M) cache vs. dual-core CPUs
  • From: David Boreham
• Re: Large (8M) cache vs. dual-core CPUs
  • From: Ron Peacetree
• Re: Large (8M) cache vs. dual-core CPUs
  • From: Bruce Momjian
• Re: Large (8M) cache vs. dual-core CPUs
  • From: Joshua D. Drake
• Re: Large (8M) cache vs. dual-core CPUs
  • From: David Boreham
• Re: ip address data type
  • From: Florian Weimer
• Re: Large (8M) cache vs. dual-core CPUs
  • From: Joshua D. Drake
• Re: planner not using index for like operator
  • From: Sriram Dandapani
• Re: Large (8M) cache vs. dual-core CPUs
  • From: Joshua D. Drake
• Re: Large (8M) cache vs. dual-core CPUs
  • From: Scott Marlowe
• Re: Large (8M) cache vs. dual-core CPUs
  • From: mark
• Re: Large (8M) cache vs. dual-core CPUs
  • From: Scott Marlowe
• Re: Slow queries salad ;)
  • From: Jim C. Nasby
• Re: Large (8M) cache vs. dual-core CPUs
  • From: Gavin Hamill
• Re: Large (8M) cache vs. dual-core CPUs
  • From: Scott Marlowe
• Re: planner not using index for like operator
  • From: Sriram Dandapani
• Re: planner not using index for like operator
  • From: Jim C. Nasby
• Re: Slow queries salad ;)
  • From: Tom Lane
• Large (8M) cache vs. dual-core CPUs
  • From: Bill Moran
• Re: planner not using index for like operator
  • From: Dave Dutcher
• Slow queries salad ;)
  • From: PFC
• planner not using index for like operator
  • From: Sriram Dandapani
• Firebird 1.5.3 X Postgresql 8.1.3 (linux and windows)
  • From: andremachado
• PL/pgSQL Loop Vs. Batch Update
  • From: David Wheeler
• Re: Query on postgresql 7.4.2 not using index
  • From: Arnau
• Re: Query on postgresql 7.4.2 not using index
  • From: Tom Lane
• Re: Query on postgresql 7.4.2 not using index
  • From: Scott Marlowe
• Re: Easy question
  • From: codeWarrior
• Re: Query on postgresql 7.4.2 not using index
  • From: Arnau
• Re: Query on postgresql 7.4.2 not using index
  • From: Tom Lane
• Re: Query on postgresql 7.4.2 not using index
  • From: Scott Marlowe
• Re: Query on postgresql 7.4.2 not using index
  • From: Guillaume Smet
• Re: Query on postgresql 7.4.2 not using index
  • From: Arnau
• Re: Query on postgresql 7.4.2 not using index
  • From: chris smith
• Query on postgresql 7.4.2 not using index
  • From: Arnau
• Re: security for row level but not based on Database user's
  • From: Richard Huxton
• Re: security for row level but not based on Database user's
  • From: Richard Huxton
• Re: Hardware: HP StorageWorks MSA 1500
  • From: Mark Kirkwood
• Re: ip address data type
  • From: Steve Atkins
• Re: ip address data type
  • From: Jim C. Nasby
• ip address data type
  • From: Sriram Dandapani
• Re: Index on function less well cached than "regular" index ?
  • From: Tom Lane
• Re: GROUP BY Vs. Sub SELECT
  • From: Jim C. Nasby
• Re: Hardware: HP StorageWorks MSA 1500
  • From: Mikael Carneholm
• Re: serious problems with vacuuming databases
  • From: Tomas Vondra
• Re: GROUP BY Vs. Sub SELECT
  • From: Richard Broersma Jr
• Re: Hardware: HP StorageWorks MSA 1500
  • From: Alex Hayward
• Re: GROUP BY Vs. Sub SELECT
  • From: Bruno Almeida do Lago
• Index on function less well cached than "regular" index ?
  • From: Paul Mackay
• Re: Slow deletes in 8.1 when FKs are involved
  • From: Jim C. Nasby
• Re: Recovery will take 10 hours
  • From: Simon Riggs
• Re: Recovery will take 10 hours
  • From: Markus Schaber
• Re: Inactive memory Grows unlimited
  • From: Matteo Beccati
• Re: Slow deletes in 8.1 when FKs are involved
  • From: Tom Lane
• Re: Recovery will take 10 hours
  • From: Brendan Duddridge
• Slow deletes in 8.1 when FKs are involved
  • From: Will Reese
• Re: Hardware: HP StorageWorks MSA 1500
  • From: Mark Kirkwood
• Re: GROUP BY Vs. Sub SELECT
  • From: Tom Lane
• GROUP BY Vs. Sub SELECT
  • From: Bruno Almeida do Lago
• Re: Recovery will take 10 hours
  • From: Simon Riggs
• Easy question
  • From: clemens . bertschler
• Re: Introducing a new linux readahead framework
  • From: Wu Fengguang
• Re: WAL logging of SELECT ... INTO command
  • From: Simon Riggs
• Re: WAL logging of SELECT ... INTO command
  • From: Bruce Momjian
• Re: Hardware: HP StorageWorks MSA 1500
  • From: Mikael Carneholm
• Re: Introducing a new linux readahead framework
  • From: Jim C. Nasby
• Worsening performance with 7.4 on flash-based system
  • From: Greg Stumph
• Re: Takes too long to fetch the data from database
  • From: Jim C. Nasby
• Re: Takes too long to fetch the data from database
  • From: Bruno Wolff III
• Re: Inactive memory Grows unlimited
  • From: Alvaro Herrera
• Inactive memory Grows unlimited
  • From: ALVARO ARCILA
• Re: Hardware: HP StorageWorks MSA 1500
  • From: Alex Hayward
• Re: Better way to write aggregates?
  • From: Tom Lane
• Re: Little use of CPU ( < 5%)
  • From: Dave Dutcher
• Re: Takes too long to fetch the data from database
  • From: Merlin Moncure
• Re: Takes too long to fetch the data from database
  • From: Dave Dutcher
• Re: Better way to write aggregates?
  • From: Jim Buttafuoco
• Re: Better way to write aggregates?
  • From: Jan Dittmer
• Re: Better way to write aggregates?
  • From: Jim Buttafuoco
• Re: Introducing a new linux readahead framework
  • From: Wu Fengguang
• security for row level but not based on Database user's login
  • From: Friends
• Little use of CPU ( < 5%)
  • From: luchot
• Better way to write aggregates?
  • From: Jan Dittmer
• Re: Introducing a new linux readahead framework
  • From: Markus Schaber
• Re: Introducing a new linux readahead framework
  • From: Wu Fengguang
• Re: Quick Performance Poll
  • From: Milen Kulev
• Re: Takes too long to fetch the data from database
  • From: soni de
• Re: Introducing a new linux readahead framework
  • From: Jim C. Nasby
• Introducing a new linux readahead framework
  • From: Wu Fengguang
• Re: Recovery will take 10 hours
  • From: Gavin Sherry
• Re: Recovery will take 10 hours
  • From: Brendan Duddridge
• Re: Recovery will take 10 hours
  • From: Brendan Duddridge
• Re: Recovery will take 10 hours
  • From: Brendan Duddridge
• Re: Recovery will take 10 hours
  • From: Tom Lane
• Re: Recovery will take 10 hours
  • From: Brendan Duddridge
• Re: Recovery will take 10 hours
  • From: Jeff Frost
• Re: Recovery will take 10 hours
  • From: Tom Lane
• Re: Recovery will take 10 hours
  • From: Brendan Duddridge
• Re: Recovery will take 10 hours
  • From: Brendan Duddridge
• Re: Recovery will take 10 hours
  • From: Brendan Duddridge
• Re: Recovery will take 10 hours
  • From: Jeff Frost
• Re: Quick Performance Poll
  • From: Luke Lonergan
• Re: Recovery will take 10 hours
  • From: Luke Lonergan
• Re: Recovery will take 10 hours
  • From: Tom Lane
• Re: Performance decrease
  • From: Guido Neitzer
• Re: Recovery will take 10 hours
  • From: Brendan Duddridge
• Re: Recovery will take 10 hours
  • From: Tom Lane
• Re: Quick Performance Poll
  • From: Milen Kulev
• Re: Inserts optimization?
  • From: Vivek Khera
• Re: Inserts optimization?
  • From: Vivek Khera
• Recovery will take 10 hours
  • From: Brendan Duddridge
• Re: Hardware: HP StorageWorks MSA 1500
  • From: Mark Lewis
• Hardware: HP StorageWorks MSA 1500
  • From: Mikael Carneholm
• Slow deletes in 8.1 when FKs are involved
  • From: Will Reese
• Re: Performance decrease
  • From: Jim C. Nasby
• Re: Quick Performance Poll
  • From: Jim C. Nasby
• Re: SELECT FOR UPDATE performance is bad
  • From: Jim C. Nasby
• Re: merge>hash>loop
  • From: Jim C. Nasby
• Re: Performance decrease
  • From: Radovan Antloga
• Re: Takes too long to fetch the data from database
  • From: Merlin Moncure
• Re: Performance decrease
  • From: Tom Lane
• Performance decrease
  • From: Radovan Antloga
• Re: Quick Performance Poll
  • From: Luke Lonergan
• IBM pSeries - overrated bucket of crud?
  • From: Gavin Hamill
• Re: Quick Performance Poll
  • From: Markus Schaber
• Re: Quick Performance Poll
  • From: Jim Buttafuoco
• Re: Quick Performance Poll
  • From: Luke Lonergan
• Re: Perfrmance Problems (7.4.6)
  • From: Ruben Rubio Rey
• Re: Quick Performance Poll
  • From: Jim Buttafuoco
• Re: Quick Performance Poll
  • From: Luke Lonergan
• Re: Inserts optimization?
  • From: Scott Marlowe
• Re: Identical query on two machines, different plans....
  • From: Csaba Nagy
• Re: Identical query on two machines, different plans....
  • From: Mario Splivalo
• Re: Identical query on two machines, different plans....
  • From: Csaba Nagy
• Identical query on two machines, different plans....
  • From: Mario Splivalo
• Re: Quick Performance Poll
  • From: Jim Buttafuoco
• Quick Performance Poll
  • From: Simon Dale
• Re: Perfrmance Problems (7.4.6)
  • From: Doron Baranes
• Re: Perfrmance Problems (7.4.6)
  • From: Ruben Rubio Rey
• Perfrmance Problems (7.4.6)
  • From: Doron Baranes
• Re: Takes too long to fetch the data from database
  • From: Bruno Wolff III
• Re: Takes too long to fetch the data from database
  • From: soni de
• Introducing a new linux readahead framework
  • From: Wu Fengguang
• Re: Inserts optimization?
  • From: Mark Kirkwood
• Re: Inserts optimization?
  • From: Christopher Kings-Lynne
• Re: Planner doesn't chose Index - (slow select)
  • From: patrick keshishian
• Re: Inserts optimization?
  • From: Scott Marlowe
• Re: Inserts optimization?
  • From: PFC
• Re: Inserts optimization?
  • From: Tom Lane
• Re: Inserts optimization?
  • From: Scott Marlowe
• Re: Inserts optimization?
  • From: Tom Lane
• Re: Inserts optimization?
  • From: Markus Schaber
• Re: Inserts optimization?
  • From: Magnus Hagander
• Re: Inserts optimization?
  • From: Markus Schaber
• Re: Multicolumn order by
  • From: Theo Kramer
• 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