Postgres Performance Date Index

• Thread Index

• Re: 0ut of Memory Error during Vacuum Analyze and Create Index
  • From: Tom Lane
• Re: 0ut of Memory Error during Vacuum Analyze and
  • From: Tomeh, Husam
• Re: 10+hrs vs 15min because of just one index
  • From: Aaron Turner
• Re: SQL Function Performance
  • From: Adnan DURSUN
• Re: 0ut of Memory Error during Vacuum Analyze and Create Index
  • From: Tom Lane
• Re: 0ut of Memory Error during Vacuum Analyze and
  • From: Tomeh, Husam
• Re: copy and postgresql.conf
  • From: Jignesh K. Shah
• 8.2.1 on FreeBSD 5.4-RELEASE
  • From: Paul Khavkine
• Re: Postgres slower than MS ACCESS
  • From: Jay Greenfield
• Re: SQL Function Performance
  • From: Michael Fuhr
• Re: Postgres slower than MS ACCESS
  • From: Tom Lane
• Re: Postgres slower than MS ACCESS
  • From: Jay Greenfield
• Re: Postgres slower than MS ACCESS
  • From: Stephen Frost
• Re: Postgres slower than MS ACCESS
  • From: Tom Lane
• Re: 0ut of Memory Error during Vacuum Analyze
  • From: Tom Lane
• Re: out of memory
  • From: Scott Marlowe
• Re: out of memory
  • From: Tom Lane
• Re: Postgres slower than MS ACCESS
  • From: Stephen Frost
• Re: copy and postgresql.conf
  • From: FERREIRA, William (VALTECH)
• Re: out of memory
  • From: Scott Marlowe
• 0ut of Memory Error during Vacuum Analyze
  • From: Tomeh, Husam
• Re: out of memory
  • From: martial . bizel
• Re: Postgres slower than MS ACCESS
  • From: Scott Marlowe
• Re: out of memory
  • From: Scott Marlowe
• Re: Postgres slower than MS ACCESS
  • From: Jay Greenfield
• Re: out of memory
  • From: martial . bizel
• Re: copy and postgresql.conf
  • From: Albert Cervera Areny
• Re: out of memory
  • From: Scott Marlowe
• Re: Postgres slower than MS ACCESS
  • From: Scott Marlowe
• Re: out of memory
  • From: martial . bizel
• Postgres slower than MS ACCESS
  • From: Jay Greenfield
• Re: out of memory
  • From: Tom Lane
• out of memory
  • From: martial . bizel
• Re: copy and postgresql.conf
  • From: FERREIRA, William (VALTECH)
• Re: copy and postgresql.conf
  • From: Albert Cervera Areny
• copy and postgresql.conf
  • From: FERREIRA, William (VALTECH)
• Re: SQL Function Performance
  • From: Adnan DURSUN
• Re: Optimizing performance of a like '%...%' condition
  • From: Chris
• Re: SQL Function Performance
  • From: Michael Fuhr
• Re: SQL Function Performance
  • From: Tom Lane
• Re: SQL Function Performance
  • From: Adnan DURSUN
• Re: SQL Function Performance
  • From: Mark Liberman
• Re: SQL Function Performance
  • From: Adnan DURSUN
• Re: SQL Function Performance
  • From: Adnan DURSUN
• Re: SQL Function Performance
  • From: Mark Liberman
• Re: SQL Function Performance
  • From: Adnan DURSUN
• Re: joining two tables slow due to sequential scan
  • From: Tim Jones
• Re: help required in design of database
  • From: Markus Schaber
• Re: 10+hrs vs 15min because of just one index
  • From: PFC
• [no subject]
  • From: Unknown
• [no subject]
  • From: Unknown
• Re: SQL Function Performance
  • From: Michael Fuhr
• Re: 10+hrs vs 15min because of just one index
  • From: Markus Schaber
• Re: SQL Function Performance
  • From: andrew
• SQL Function Performance
  • From: Adnan DURSUN
• Re: 10+hrs vs 15min because of just one index
  • From: Aaron Turner
• Re: 10+hrs vs 15min because of just one index
  • From: Aaron Turner
• Re: 10+hrs vs 15min because of just one index
  • From: Marc Morin
• Re: 10+hrs vs 15min because of just one index
  • From: Tom Lane
• Re: 10+hrs vs 15min because of just one index
  • From: Aaron Turner
• Re: 10+hrs vs 15min because of just one index
  • From: Jim C. Nasby
• Re: Storing Digital Video
  • From: Jim C. Nasby
• Re: [HACKERS] What do the Windows pg hackers out there like for dev
  • From: Mark Kirkwood
• Re: postgresql geqo optimization
  • From: Steinar H. Gunderson
• postgresql geqo optimization
  • From: uwcssa
• Re: joining two tables slow due to sequential scan
  • From: Dave Dutcher
• Re: joining two tables slow due to sequential scan
  • From: Tim Jones
• Re: joining two tables slow due to sequential scan
  • From: Tom Lane
• Re: joining two tables slow due to sequential scan
  • From: Scott Marlowe
• Re: joining two tables slow due to sequential scan
  • From: Tom Lane
• Re: joining two tables slow due to sequential scan
  • From: Tim Jones
• Re: Large Database Design Help
  • From: Scott Marlowe
• Re: joining two tables slow due to sequential scan
  • From: Scott Marlowe
• Re: Large Database Design Help
  • From: Ragnar
• Re: joining two tables slow due to sequential scan
  • From: Tim Jones
• Re: joining two tables slow due to sequential scan
  • From: Scott Marlowe
• Re: joining two tables slow due to sequential scan
  • From: Tim Jones
• Re: joining two tables slow due to sequential scan
  • From: Scott Marlowe
• Re: joining two tables slow due to sequential scan
  • From: Dave Dutcher
• joining two tables slow due to sequential scan
  • From: Tim Jones
• Re: help required in design of database
  • From: Steinar H. Gunderson
• help required in design of database
  • From: david drummard
• Re: Large Database Design Help
  • From: PFC
• Re: Basic Database Performance
  • From: PFC
• What do the Windows pg hackers out there like for dev tools?
  • From: Ron
• Re: 10+hrs vs 15min because of just one index
  • From: Aaron Turner
• Re: 10+hrs vs 15min because of just one index
  • From: Matthew T. O'Connor
• Re: 10+hrs vs 15min because of just one index
  • From: Aaron Turner
• Re: pgbench output
  • From: Gourish Singbal
• Re: Basic Database Performance
  • From: Markus Schaber
• Re: Large Database Design Help
  • From: Markus Schaber
• Re: Large Database Design Help
  • From: Markus Schaber
• Re: Basic Database Performance
  • From: James Dey
• Re: Basic Database Performance
  • From: Richard Huxton
• Re: Basic Database Performance
  • From: Richard Huxton
• Re: 10+hrs vs 15min because of just one index
  • From: hubert depesz lubaczewski
• Basic Database Performance
  • From: James Dey
• 10+hrs vs 15min because of just one index
  • From: Aaron Turner
• Re: Help with optimizing a sql statement
  • From: Greg Stark
• Re: Help with optimizing a sql statement
  • From: Vivek Khera
• Re: Help with optimizing a sql statement
  • From: Rafael Martinez
• Re: Help with optimizing a sql statement
  • From: Tom Lane
• Re: Storing Digital Video
  • From: Jan Peterson
• Re: Help with optimizing a sql statement
  • From: Rafael Martinez
• Re: Large Database Design Help
  • From: Matthew Nuzum
• Re: Help with optimizing a sql statement
  • From: Jim C. Nasby
• Re: Large Database Design Help
  • From: Greg Stark
• Re: Large Database Design Help
  • From: Jim C. Nasby
• Re: Help with optimizing a sql statement
  • From: Dave Dutcher
• Re: Help with optimizing a sql statement
  • From: Jim C. Nasby
• Re: Storing Digital Video
  • From: Jim C. Nasby
• Large Database Design Help
  • From: Orion Henry
• Re: Storing Digital Video
  • From: Nate Byrnes
• Re: Storing Digital Video
  • From: Craig A. James
• Help with optimizing a sql statement
  • From: Rafael Martinez Guerrero
• Re: Storing Digital Video
  • From: Nate Byrnes
• Re: Sane configuration options for a WinXP laptop 8.1 install?
  • From: Jim C. Nasby
• Re: Default autovacuum settings too conservative
  • From: Markus Schaber
• Re: Default autovacuum settings too conservative
  • From: Tim Allen
• Sane configuration options for a WinXP laptop 8.1 install?
  • From: Ron
• Re: Default autovacuum settings too conservative
  • From: Markus Schaber
• Re: Size and performance hit from using UTF8 vs. ASCII?
  • From: Jeffrey W. Baker
• Re: optimizing away join when querying view
  • From: Stephan Szabo
• Re: optimizing away join when querying view
  • From: Tom Lane
• Size and performance hit from using UTF8 vs. ASCII?
  • From: Ron
• optimizing away join when querying view
  • From: Jacob Costello
• Re: Default autovacuum settings too conservative
  • From: Markus Schaber
• Re: partitioning and locking problems
  • From: Simon Riggs
• Re: Default autovacuum settings too conservative
  • From: Christopher Browne
• Re: Default autovacuum settings too conservative
  • From: Russell Smith
• Re: Default autovacuum settings too conservative
  • From: Jim C. Nasby
• Re: partitioning and locking problems
  • From: Jim C. Nasby
• Re: partitioning and locking problems
  • From: Marc Morin
• Re: partitioning and locking problems
  • From: Ron
• Re: partitioning and locking problems
  • From: Simon Riggs
• Re: Default autovacuum settings too conservative
  • From: Michael Stone
• Re: Default autovacuum settings too conservative
  • From: Markus Schaber
• Re: Default autovacuum settings too conservative
  • From: Jim C. Nasby
• Re: Default autovacuum settings too conservative
  • From: Christopher Browne
• Re: pgbench output
  • From: Jim C. Nasby
• Re: Default autovacuum settings too conservative
  • From: Jim C. Nasby
• Re: partitioning and locking problems
  • From: Jim C. Nasby
• Re: Default autovacuum settings too conservative
  • From: Chris Browne
• Re: execution plan : Oracle vs PostgreSQL
  • From: Andrew Lazarus
• Re: Default autovacuum settings too conservative
  • From: Vivek Khera
• Re: Storing Digital Video
  • From: Albert Cervera Areny
• Re: Index occupancy
  • From: Tom Lane
• Re: Huge Data sets, simple queries
  • From: Alan Stange
• Re: Planner reluctant to start from subquery
  • From: Tom Lane
• Re: partitioning and locking problems
  • From: Marc Morin
• Index occupancy
  • From: tschak
• Re: partitioning and locking problems
  • From: Markus Schaber
• Re: Where is my bottleneck?
  • From: Markus Schaber
• pgbench output
  • From: Pradeep Parmar
• Re: Huge Data sets, simple queries
  • From: Luke Lonergan
• Re: Index Usage using IN
  • From: Hari Warrier
• Re: Default autovacuum settings too conservative
  • From: Matthew T. O'Connor
• Default autovacuum settings too conservative
  • From: Jim C. Nasby
• Re: Index Usage using IN
  • From: Bruno Wolff III
• Re: Planner reluctant to start from subquery
  • From: Tom Lane
• Re: Planner reluctant to start from subquery
  • From: Kevin Grittner
• Re: Planner reluctant to start from subquery
  • From: Kevin Grittner
• Re: Index Usage using IN
  • From: Tom Lane
• Re: Planner reluctant to start from subquery
  • From: Tom Lane
• Re: Index Usage using IN
  • From: Jeffrey W. Baker
• Re: Planner reluctant to start from subquery
  • From: Kevin Grittner
• Re: Index Usage using IN
  • From: Jeffrey W. Baker
• Index Usage using IN
  • From: Ralph Mason
• Re: Planner reluctant to start from subquery
  • From: Tom Lane
• Re: Planner reluctant to start from subquery
  • From: Kevin Grittner
• Re: Planner reluctant to start from subquery
  • From: Tom Lane
• Planner reluctant to start from subquery
  • From: Kevin Grittner
• Re: Huge Data sets, simple queries
  • From: Mike Rylander
• Re: Huge Data sets, simple queries
  • From: Steinar H. Gunderson
• Re: Huge Data sets, simple queries
  • From: Luke Lonergan
• Re: execution plan : Oracle vs PostgreSQL
  • From: FERREIRA, William (VALTECH)
• Re: execution plan : Oracle vs PostgreSQL
  • From: Tom Lane
• Re: partitioning and locking problems
  • From: Tom Lane
• Re: partitioning and locking problems
  • From: Marc Morin
• Re: Huge Data sets, simple queries
  • From: Michael Stone
• execution plan : Oracle vs PostgreSQL
  • From: FERREIRA, William (VALTECH)
• Re: partitioning and locking problems
  • From: Richard Huxton
• Re: Huge Data sets, simple queries
  • From: PFC
• Re: Huge Data sets, simple queries
  • From: Jeffrey W. Baker
• Re: Huge Data sets, simple queries
  • From: Luke Lonergan
• Re: partitioning and locking problems
  • From: Tom Lane
• Re: Sequential scan being used despite indexes
  • From: Michael Fuhr
• Re: Sequential scan being used despite indexes
  • From: Christopher Kings-Lynne
• Re: Sequential scan being used despite indexes
  • From: James Russell
• Re: Huge Data sets, simple queries
  • From: Jeffrey W. Baker
• Re: Sequential scan being used despite indexes
  • From: Michael Fuhr
• Re: Sequential scan being used despite indexes
  • From: Joshua D. Drake
• Sequential scan being used despite indexes
  • From: James Russell
• Re: Huge Data sets, simple queries
  • From: Jim C. Nasby
• Re: Huge Data sets, simple queries
  • From: Luke Lonergan
• Re: Huge Data sets, simple queries
  • From: Steinar H. Gunderson
• Re: Storing Digital Video
  • From: Matt Davies | Postgresql List
• Re: Storing Digital Video
  • From: Jeffrey W. Baker
• Storing Digital Video
  • From: Rodrigo Madera
• partitioning and locking problems
  • From: Marc Morin
• Re: Huge Data sets, simple queries
  • From: Luke Lonergan
• Re: Huge Data sets, simple queries
  • From: Luke Lonergan
• Re: Huge Data sets, simple queries
  • From: Jim C. Nasby
• Re: Huge Data sets, simple queries
  • From: PFC
• Re: Huge Data sets, simple queries
  • From: Luke Lonergan
• Re: Huge Data sets, simple queries
  • From: Luke Lonergan
• Re: Huge Data sets, simple queries
  • From: Jeffrey W. Baker
• Re: Delete me
  • From: Jim C. Nasby
• Re: Huge Data sets, simple queries
  • From: Jim C. Nasby
• Re: Delete me
  • From: Richard Huxton
• Re: Huge Data sets, simple queries
  • From: Kevin
• Re: Huge Data sets, simple queries
  • From: Luke Lonergan
• Delete me
  • From: 2386429
• Re: Query planner issue
  • From: Tom Lane
• Re: Where is my bottleneck?
  • From: Richard Huxton
• Re: Query planner issue
  • From: Emmanuel Lacour
• Re: Query planner issue
  • From: Jim Buttafuoco
• Re: Query planner issue
  • From: Mark Lewis
• Query planner issue
  • From: Emmanuel Lacour
• Re: Huge Data sets, simple queries
  • From: Jim C. Nasby
• Re: Where is my bottleneck?
  • From: Jim C. Nasby
• Re: Huge Data sets, simple queries
  • From: Luke Lonergan
• Re: Huge Data sets, simple queries
  • From: hubert depesz lubaczewski
• Re: Where is my bottleneck?
  • From: Luke Lonergan
• Re: Where is my bottleneck?
  • From: Michael Stone
• Re: Huge Data sets, simple queries
  • From: Luke Lonergan
• Re: Huge Data sets, simple queries
  • From: Charles Sprickman
• Re: Desperate: View not using indexes (very slow)
  • From: Tom Lane
• Re: Huge Data sets, simple queries
  • From: Craig A. James
• Re: Huge Data sets, simple queries
  • From: Michael Adler
• Re: Huge Data sets, simple queries
  • From: Jeffrey W. Baker
• Re: Huge Data sets, simple queries
  • From: Luke Lonergan
• Re: Huge Data sets, simple queries
  • From: Michael Stone
• Re: Huge Data sets, simple queries
  • From: hubert depesz lubaczewski
• Re: Huge Data sets, simple queries
  • From: Tom Lane
• Re: Huge Data sets, simple queries
  • From: Luke Lonergan
• Re: Huge Data sets, simple queries
  • From: Tom Lane
• Re: Huge Data sets, simple queries
  • From: Jeffrey W. Baker
• Re: Huge Data sets, simple queries
  • From: Tom Lane
• Re: Huge Data sets, simple queries
  • From: Jeffrey W. Baker
• Huge Data sets, simple queries
  • From: Mike Biamonte
• Re: [GENERAL] Creation of tsearch2 index is very
  • From: Ron
• Re: [GENERAL] Creation of tsearch2 index is very
  • From: Ron
• Re: [GENERAL] Creation of tsearch2 index is very
  • From: Craig A. James
• Re: [GENERAL] Creation of tsearch2 index is very
  • From: Ron
• Re: [GENERAL] Creation of tsearch2 index is very
  • From: Alvaro Herrera
• Re: [GENERAL] Creation of tsearch2 index is very
  • From: Ron
• Re: Incorrect Total runtime Reported by Explain Analyze!?
  • From: Jozsef Szalay
• Re: Incorrect Total runtime Reported by Explain Analyze!?
  • From: Scott Marlowe
• Re: Incorrect Total runtime Reported by Explain Analyze!?
  • From: Michael Fuhr
• Re: Incorrect Total runtime Reported by Explain Analyze!?
  • From: Jozsef Szalay
• Re: Query optimization with X Y JOIN
  • From: J
• Re: Incorrect Total runtime Reported by Explain Analyze!?
  • From: Richard Huxton
• Re: Query optimization with X Y JOIN
  • From: Richard Huxton
• Re: Incorrect Total runtime Reported by Explain Analyze!?
  • From: Scott Marlowe
• Re: Query optimization with X Y JOIN
  • From: Joshua D. Drake
• Re: Query optimization with X Y JOIN
  • From: J
• Re: Query optimization with X Y JOIN
  • From: Craig A. James
• Incorrect Total runtime Reported by Explain Analyze!?
  • From: Jozsef Szalay
• Query optimization with X Y JOIN
  • From: J
• Re: PostgreSQL Solaris packages now in beta
  • From: Jignesh K. Shah
• Re: Physical column size
  • From: Mario Weilguni
• Physical column size
  • From: Paul Mackay
• PostgreSQL Solaris packages now in beta
  • From: Robert Lor
• Re: DB responce during DB dump
  • From: Evgeny Gridasov
• Re: DB responce during DB dump
  • From: Evgeny Gridasov
• Re: DB responce during DB dump
  • From: Tom Lane
• Desperate: View not using indexes (very slow)
  • From: Jen Sale
• Re: DB responce during DB dump
  • From: Richard Huxton
• DB responce during DB dump
  • From: Evgeny Gridasov
• Re: Inconsistant query plan
  • From: Alessandro Baretta
• Re: Inconsistant query plan
  • From: Daniel Gish
• Re: Inconsistant query plan
  • From: Michael Fuhr
• Re: Inconsistant query plan
  • From: Scott Marlowe
• Inconsistant query plan
  • From: Daniel Gish
• Re: Investigating IO Saturation
  • From: Andrew Sullivan
• Re: Investigating IO Saturation
  • From: Chris Browne
• Where is my bottleneck?
  • From: Arnau Rebassa Villalonga
• Re: Investigating IO Saturation
  • From: Joshua D. Drake
• Re: Investigating IO Saturation
  • From: Tom Lane
• Re: Investigating IO Saturation
  • From: Brad Nicholson
• Re: Investigating IO Saturation
  • From: Joshua D. Drake
• Investigating IO Saturation
  • From: Brad Nicholson
• unsubscribe
  • From: Adnan HOTMAIL
• Re: Slow queries consisting inner selects and order bys & hack to speed up
  • From: Tom Lane
• Re: [PERFORMANCE] Stored Procedures
  • From: Frank Wiles
• Re: [PERFORMANCE] Stored Procedures
  • From: Dave Dutcher
• Re: [PERFORMANCE] Stored Procedures
  • From: Marcos
• Re: [PERFORMANCE] Stored Procedures
  • From: Markus Schaber
• Re: Suspending SELECTs
  • From: Alessandro Baretta
• Re: [PERFORMANCE] Stored Procedures
  • From: Marcos
• ENC: RES: pg_dump slow - Solution
  • From: Franklin Haut
• Re: tsearch2 headline and postgresql.conf
  • From: pgsql-performance
• Re: Suspending SELECTs
  • From: August Zajonc
• Re: tsearch2 headline and postgresql.conf
  • From: Oleg Bartunov
• tsearch2 headline and postgresql.conf
  • From: pgsql-performance
• Re: libpq vs. unixODBC performance
  • From: Tom Lane
• libpq vs. unixODBC performance
  • From: Constantine Filin
• Re: [PERFORMANCE] Stored Procedures
  • From: Rikard Pavelic
• Re: [GENERAL] Creation of tsearch2 index is very
  • From: Tom Lane
• Slow queries consisting inner selects and order bys & hack to speed up
  • From: Ümit Öztosun
• Re: [GENERAL] Creation of tsearch2 index is very
  • From: David Lang
• Re: [GENERAL] Creation of tsearch2 index is very slow
  • From: Martijn van Oosterhout
• Re: [GENERAL] Creation of tsearch2 index is very
  • From: Tom Lane
• Re: [GENERAL] Creation of tsearch2 index is very slow
  • From: Oleg Bartunov
• Re: [GENERAL] Creation of tsearch2 index is very slow
  • From: Oleg Bartunov
• Re: [GENERAL] Creation of tsearch2 index is very
  • From: Ron
• Re: [GENERAL] Creation of tsearch2 index is very
  • From: Oleg Bartunov
• Re: [GENERAL] Creation of tsearch2 index is very slow
  • From: Martijn van Oosterhout
• Re: SELECT MIN, MAX took longer time than SELECT
  • From: K C Lau
• Re: [GENERAL] Creation of tsearch2 index is very
  • From: Oleg Bartunov
• Re: [GENERAL] Creation of tsearch2 index is very slow
  • From: Oleg Bartunov
• Re: SELECT MIN, MAX took longer time than SELECT
  • From: K C Lau
• Re: [GENERAL] Creation of tsearch2 index is very slow
  • From: Martijn van Oosterhout
• Re: [GENERAL] Creation of tsearch2 index is very
  • From: Ron
• Re: [PERFORMANCE] Stored Procedures
  • From: Rikard Pavelic
• Re: [GENERAL] Creation of tsearch2 index is very slow
  • From: Craig A. James
• Re: [GENERAL] Creation of tsearch2 index is very slow
  • From: Steinar H. Gunderson
• Re: [GENERAL] Creation of tsearch2 index is very slow
  • From: Tom Lane
• Re: [GENERAL] Creation of tsearch2 index is very slow
  • From: Steinar H. Gunderson
• Re: [GENERAL] Creation of tsearch2 index is very slow
  • From: Tom Lane
• Re: [GENERAL] Creation of tsearch2 index is very slow
  • From: Steinar H. Gunderson
• Re: [GENERAL] Creation of tsearch2 index is very slow
  • From: Steinar H. Gunderson
• Re: [GENERAL] Creation of tsearch2 index is very slow
  • From: Steinar H. Gunderson
• Re: [GENERAL] Creation of tsearch2 index is very slow
  • From: Martijn van Oosterhout
• Re: [GENERAL] Creation of tsearch2 index is very slow
  • From: Tom Lane
• Re: [GENERAL] Creation of tsearch2 index is very slow
  • From: Steinar H. Gunderson
• Re: [GENERAL] Creation of tsearch2 index is very slow
  • From: Ron
• Re: [GENERAL] Creation of tsearch2 index is very slow
  • From: Martijn van Oosterhout
• Re: [GENERAL] Creation of tsearch2 index is very slow
  • From: Ron
• Re: [GENERAL] Creation of tsearch2 index is very slow
  • From: Steinar H. Gunderson
• Re: Sudden slowdown of Pg server
  • From: Jignesh K. Shah
• Sudden slowdown of Pg server
  • From: Jerry Sievers
• Re: [GENERAL] Creation of tsearch2 index is very slow
  • From: Tom Lane
• Re: [GENERAL] Creation of tsearch2 index is very slow
  • From: Steinar H. Gunderson
• Re: [GENERAL] Creation of tsearch2 index is very slow
  • From: Martijn van Oosterhout
• Re: [PERFORMANCE] Stored Procedures
  • From: Jim C. Nasby
• Re: [GENERAL] Creation of tsearch2 index is very slow
  • From: Tom Lane
• Re: [GENERAL] Creation of tsearch2 index is very slow
  • From: Martijn van Oosterhout
• Re: [GENERAL] Creation of tsearch2 index is very slow
  • From: Tom Lane
• Re: [GENERAL] Creation of tsearch2 index is very slow
  • From: Martijn van Oosterhout
• Re: [PERFORMANCE] Stored Procedures
  • From: Rikard Pavelic
• Re: [GENERAL] Creation of tsearch2 index is very slow
  • From: Tom Lane
• Re: [PERFORMANCE] Stored Procedures
  • From: Jim C. Nasby
• Re: query stopped working after tables > 50000 records
  • From: Jim C. Nasby
• Re: Autovacuum / full vacuum (off-topic?)
  • From: Jim C. Nasby
• Re: Stored procedures
  • From: Rikard Pavelic
• Re: SELECT MIN, MAX took longer time than SELECT COUNT, MIN, MAX
  • From: Tom Lane
• Re: [PERFORMANCE] Stored Procedures
  • From: Rikard Pavelic
• query stopped working after tables > 50000 records
  • From: Antoine
• Re: Autovacuum / full vacuum (off-topic?)
  • From: me
• Re: Autovacuum / full vacuum (off-topic?)
  • From: Jim C. Nasby
• Re: Autovacuum / full vacuum (off-topic?)
  • From: Joshua D. Drake
• Re: Autovacuum / full vacuum (off-topic?)
  • From: Jim C. Nasby
• Re: Autovacuum / full vacuum (off-topic?)
  • From: Joshua D. Drake
• Re: SELECT MIN, MAX took longer time than SELECT COUNT, MIN, MAX
  • From: Jim C. Nasby
• Re: Autovacuum / full vacuum (off-topic?)
  • From: Jim C. Nasby
• Re: Extremely irregular query performance
  • From: Bruce Momjian
• Re: Extremely irregular query performance
  • From: Tom Lane
• Re: Extremely irregular query performance
  • From: Bruce Momjian
• Re: Retaining execution plans between connections?
  • From: Neil Conway
• Re: Retaining execution plans between connections?
  • From: Pandurangan R S
• Retaining execution plans between connections?
  • From: James Russell
• SELECT MIN, MAX took longer time than SELECT COUNT, MIN, MAX
  • From: K C Lau
• Re: Autovacuum / full vacuum (off-topic?)
  • From: Bruce Momjian
• Re: Autovacuum / full vacuum (off-topic?)
  • From: Mark Kirkwood
• Re: 3WARE Card performance boost?
  • From: Alex Turner
• Re: Stable function being evaluated more than once in a single
  • From: Bruce Momjian
• Re: query plans different for 8.1 on windows and aix
  • From: Tom Lane
• query plans different for 8.1 on windows and aix
  • From: Tim Jones
• Re: 3WARE Card performance boost?
  • From: Vivek Khera
• Re: Stored Procedures
  • From: Andreas Kretschmer
• Stored Procedures
  • From: Benjamin Arai
• Re: Use of Stored Procedures and
  • From: Markus Schaber
• Re: Use of Stored Procedures and
  • From: Marcos
• Re: Use of Stored Procedures and
  • From: Markus Schaber
• Re: Use of Stored Procedures and
  • From: Marcos
• Re: Autovacuum / full vacuum (off-topic?)
  • From: Jim C. Nasby
• Re: Autovacuum / full vacuum (off-topic?)
  • From: Michael Crozier
• Re: Autovacuum / full vacuum (off-topic?)
  • From: Michael Crozier
• Re: 3WARE Card performance boost?
  • From: Jim C. Nasby
• Re: Autovacuum / full vacuum (off-topic?)
  • From: Chris Browne
• Re: Simple Question of Performance ILIKE or Lower
  • From: Jim C. Nasby
• Re: Autovacuum / full vacuum (off-topic?)
  • From: Jim C. Nasby
• Re: Autovacuum / full vacuum
  • From: Jim C. Nasby
• Re: 3WARE Card performance boost?
  • From: William Yu
• Re: 3WARE Card performance boost?
  • From: Steinar H. Gunderson
• Re: 3WARE Card performance boost?
  • From: William Yu
• Re: Use of Stored Procedures and
  • From: Michael Fuhr
• Re: Multiple Order By Criteria
  • From: J
• Re: 3WARE Card performance boost?
  • From: Joost Kraaijeveld
• Re: 3WARE Card performance boost?
  • From: Alex Turner
• Re: Autovacuum / full vacuum (off-topic?)
  • From: Michael Crozier
• Re: 3WARE Card performance boost?
  • From: Alex Turner
• Re: SAN/NAS options
  • From: Michael Adler
• Re: 3WARE Card performance boost?
  • From: Benjamin Arai
• Re: 3WARE Card performance boost?
  • From: Joshua D. Drake
• 3WARE Card performance boost?
  • From: Benjamin Arai
• Re: Autovacuum / full vacuum
  • From: Chris Browne
• Re: Autovacuum / full vacuum
  • From: Alvaro Herrera
• Re: Suspending SELECTs
  • From: mark
• Re: Autovacuum / full vacuum
  • From: Mindaugas
• Re: Suspending SELECTs
  • From: Harry Jackson
• Re: Suspending SELECTs
  • From: Alessandro Baretta
• Re: Multiple Order By Criteria
  • From: Stephan Szabo
• Re: wildcard search performance with "like"
  • From: Michael Riess
• Re: Suspending SELECTs
  • From: mark
• Re: Autovacuum / full vacuum
  • From: Michael Riess
• Re: Multiple Order By Criteria
  • From: J
• Simple Question of Performance ILIKE or Lower
  • From: Marcos
• Re: Suspending SELECTs
  • From: Alessandro Baretta
• Re: Suspending SELECTs
  • From: Tino Wildenhain
• Re: Suspending SELECTs
  • From: Alessandro Baretta
• Re: Suspending SELECTs
  • From: Mark Kirkwood
• Re: Multiple Order By Criteria
  • From: Ahmad Fajar
• Re: Getting pg to use index on an inherited table (8.1.1)
  • From: Tom Lane
• Re: Suspending SELECTs
  • From: Tom Lane
• Re: Suspending SELECTs
  • From: Craig A. James
• Getting pg to use index on an inherited table (8.1.1)
  • From: Hari Warrier
• Re: Suspending SELECTs
  • From: Mark Kirkwood
• Re: Multiple Order By Criteria
  • From: J
• Re: Multiple Order By Criteria
  • From: Stephan Szabo
• Re: Suspending SELECTs
  • From: Josh Berkus
• Re: Multiple Order By Criteria
  • From: J
• Re: Multiple Order By Criteria
  • From: Fredrick O Jackson
• Re: Suspending SELECTs
  • From: Josh Berkus
• Re: Suspending SELECTs
  • From: Frank Wiles
• Re: Autovacuum / full vacuum
  • From: Jim C. Nasby
• Re: Multiple Order By Criteria
  • From: Stephan Szabo
• Re: Multiple Order By Criteria
  • From: J
• Re: Multiple Order By Criteria
  • From: Josh Berkus
• Multiple Order By Criteria
  • From: J
• Re: Suspending SELECTs
  • From: Mark Lewis
• Re: Suspending SELECTs
  • From: mark
• Re: sum of left join greater than its parts
  • From: Josh Berkus
• Re: wildcard search performance with "like"
  • From: Tom Lane
• Re: Suspending SELECTs
  • From: Jim C. Nasby
• Re: Ensuring data integrity with fsync=off
  • From: Jim C. Nasby
• Re: big databases & hospitals
  • From: Jim C. Nasby
• Re: Suspending SELECTs
  • From: Tom Lane
• wildcard search performance with "like"
  • From: Yantao Shi
• Re: Suspending SELECTs
  • From: Alessandro Baretta
• Re: Suspending SELECTs
  • From: Michael Stone
• Re: Suspending SELECTs
  • From: Alessandro Baretta
• Re: Autovacuum / full vacuum
  • From: Tom Lane
• Re: Autovacuum / full vacuum
  • From: Chris Browne
• Re: Autovacuum / full vacuum
  • From: Andrew Sullivan
• Re: Autovacuum / full vacuum
  • From: Scott Marlowe
• Re: Autovacuum / full vacuum
  • From: Alvaro Herrera
• Re: Autovacuum / full vacuum
  • From: Markus Schaber
• Re: Autovacuum / full vacuum
  • From: Andrew Sullivan
• sum of left join greater than its parts
  • From: Robert Treat
• Re: Autovacuum / full vacuum
  • From: Chris Browne
• Re: Autovacuum / full vacuum
  • From: Scott Marlowe
• Re: Autovacuum / full vacuum
  • From: Tom Lane
• Re: Autovacuum / full vacuum
  • From: Andrew Sullivan
• Re: Autovacuum / full vacuum
  • From: Andrew Sullivan
• Re: Autovacuum / full vacuum
  • From: Tom Lane
• Re: Autovacuum / full vacuum
  • From: hubert depesz lubaczewski
• Re: Autovacuum / full vacuum
  • From: Andrew Sullivan
• Re: Autovacuum / full vacuum
  • From: Andrew Sullivan
• Re: Autovacuum / full vacuum
  • From: Michael Stone
• Re: Autovacuum / full vacuum
  • From: Michael Riess
• Re: Autovacuum / full vacuum
  • From: Andrew Sullivan
• Re: Autovacuum / full vacuum
  • From: Michael Riess
• Re: Autovacuum / full vacuum
  • From: Christopher Browne
• Re: Autovacuum / full vacuum
  • From: Larry Rosenman
• Re: Autovacuum / full vacuum
  • From: Michael Riess
• Re: Autovacuum / full vacuum
  • From: Markus Schaber
• Re: Autovacuum / full vacuum
  • From: Matthew T. O'Connor
• Re: Autovacuum / full vacuum
  • From: Michael Riess
• Re: Autovacuum / full vacuum
  • From: Christopher Browne
• Re: new to postgres (and db management) and performance
  • From: Markus Schaber
• Re: new to postgres (and db management) and performance
  • From: Markus Schaber
• Re: new to postgres (and db management) and performance already a problem :-(
  • From: Andrew Sullivan
• Re: Autovacuum / full vacuum
  • From: Alvaro Herrera
• Re: Autovacuum / full vacuum
  • From: Michael Stone
• Re: Autovacuum / full vacuum
  • From: Pandurangan R S
• Use of Stored Procedures and
  • From: Marcos
• Re: Autovacuum / full vacuum
  • From: Michael Riess
• Re: Autovacuum / full vacuum
  • From: Christopher Kings-Lynne
• Autovacuum / full vacuum
  • From: Michael Riess
• Re: new to postgres (and db management) and performance already a problem :-(
  • From: Antoine
• Re: new to postgres (and db management) and performance already a problem :-(
  • From: me
• Re: new to postgres (and db management) and performance already a problem :-(
  • From: Christopher Browne
• Re: new to postgres (and db management) and performance already a problem :-(
  • From: me
• Re: new to postgres (and db management) and performance already a problem :-(
  • From: Tom Lane
• Re: new to postgres (and db management) and performance already a problem :-(
  • From: me
• Re: new to postgres (and db management) and performance already a problem :-(
  • From: Tom Lane
• Re: new to postgres (and db management) and performance already a problem :-(
  • From: Andrew Sullivan
• new to postgres (and db management) and performance already a problem :-(
  • From: Antoine
• Re: Use of * affect the performance
  • From: Qingqing Zhou
• Re: Suspending SELECTs
  • From: Craig A. James
• Re: Suspending SELECTs
  • From: Mark Lewis
• Re: Suspending SELECTs
  • From: Tom Lane
• Re: Suspending SELECTs
  • From: Alvaro Herrera
• Re: Suspending SELECTs
  • From: Tom Lane
• Use of * affect the performance
  • From: Marcos
• Re: Materialized Views
  • From: Michael Riess
• Re: Materialized Views
  • From: me
• Re: Materialized Views
  • From: Frank Wiles
• Materialized Views
  • From: Michael Riess
• Suspending SELECTs
  • From: Alessandro Baretta
• Re: SAN/NAS options
  • From: Luke Lonergan
• Re: SAN/NAS options
  • From: Christopher Browne
• Re: SAN/NAS options
  • From: Luke Lonergan
• Re: SAN/NAS options
  • From: Charles Sprickman
• Re: SAN/NAS options
  • From: Charles Sprickman
• Re: big databases & hospitals
  • From: Jaime Casanova
• Re: Ensuring data integrity with fsync=off
  • From: Tom Lane
• Re: big databases & hospitals
  • From: Chris Mair
• Ensuring data integrity with fsync=off
  • From: Benjamin Arai
• Re: >= forces row compare and not index elements compare when possible
  • From: Tom Lane
• Re: Hanging Query
  • From: Tom Lane
• Re: big databases & hospitals
  • From: Tomka Gergely
• Re: big databases & hospitals
  • From: Javier Carlos
• big databases & hospitals
  • From: Tomka Gergely
• Re: Extremely irregular query performance
  • From: Bruce Momjian
• Re: Stable function being evaluated more than once in a single query
  • From: Jim C. Nasby
• Re: Stable function being evaluated more than once in a single query
  • From: Tom Lane
• Re: Throwing unnecessary joins away
  • From: Jim C. Nasby
• Re: Throwing unnecessary joins away
  • From: Jim C. Nasby
• Re: Stable function being evaluated more than once in a single query
  • From: Jim C. Nasby
• Re: Slow query with joins
  • From: Jim C. Nasby
• Re: insert without oids
  • From: Michael Stone
• Re: insert without oids
  • From: Neil Conway
• Re: insert without oids
  • From: Michael Fuhr
• insert without oids
  • From: Michael Stone
• Re: Please Help: PostgreSQL performance Optimization
  • From: Frank Wiles
• Re: Please Help: PostgreSQL performance Optimization
  • From: Jamal Ghaffour
• [no subject]
  • From: Unknown
• Re: Extremely irregular query performance
  • From: Kenneth Marshall
• Re: Please Help: PostgreSQL performance Optimization
  • From: Jaime Casanova
• Re: Extremely irregular query performance
  • From: Jean-Philippe Cote
• Re: Extremely irregular query performance
  • From: Kenneth Marshall
• Re: Throwing unnecessary joins away
  • From: Ottó Havasvölgyi
• Re: Please Help: PostgreSQL performance Optimization
  • From: Andrew Lazarus
• Re: Throwing unnecessary joins away
  • From: Scott Marlowe
• Re: Throwing unnecessary joins away
  • From: Ottó Havasvölgyi
• Re: Throwing unnecessary joins away
  • From: Szűcs Gábor
• Re: Throwing unnecessary joins away
  • From: Tom Lane
• Re: Please Help: PostgreSQL performance Optimization
  • From: Jamal Ghaffour
• query slower on 8.1 than 7.3
  • From: Robert Treat
• Re: Throwing unnecessary joins away
  • From: Ottó Havasvölgyi
• Re: Throwing unnecessary joins away
  • From: Alessandro Baretta
• Throwing unnecessary joins away
  • From: Ottó Havasvölgyi
• Re: Extremely irregular query performance
  • From: Simon Riggs
• Re: indexes on primary and foreign keys
  • From: Tom Lane
• Re: Stable function being evaluated more than once in a single query
  • From: Tom Lane
• Re: Index isn't used during a join.
  • From: Robert Creager
• Re: indexes on primary and foreign keys
  • From: K C Lau
• Re: Extremely irregular query performance
  • From: Tom Lane
• Re: indexes on primary and foreign keys
  • From: Michael Fuhr
• Re: indexes on primary and foreign keys
  • From: Michael Glaesemann
• Re: indexes on primary and foreign keys
  • From: K C Lau
• Re: NOT LIKE much faster than LIKE?
  • From: Simon Riggs
• Stable function being evaluated more than once in a single query
  • From: Mark Liberman
• Please Help: PostgreSQL performance Optimization
  • From: Jamal Ghaffour
• Re: indexes on primary and foreign keys
  • From: Burak Seydioglu
• Re: Extremely irregular query performance
  • From: Mark Lewis
• Re: Extremely irregular query performance
  • From: Jean-Philippe Côté
• Re: Extremely irregular query performance
  • From: Scott Marlowe
• Re: indexes on primary and foreign keys
  • From: Michael Fuhr
• Re: indexes on primary and foreign keys
  • From: Tom Lane
• Re: Extremely irregular query performance
  • From: Tom Lane
• indexes on primary and foreign keys
  • From: Burak Seydioglu
• Extremely irregular query performance
  • From: Jean-Philippe Côté
• Re: Showing Column Statistics Number
  • From: Michael Fuhr
• Showing Column Statistics Number
  • From: Dave Dutcher
• Re: Slow query with joins
  • From: Bendik Rognlien Johansen
• Re: NOT LIKE much faster than LIKE?
  • From: Tom Lane
• Re: NOT LIKE much faster than LIKE?
  • From: Jim C. Nasby
• Re: NOT LIKE much faster than LIKE?
  • From: Andrea Arcangeli
• Re: NOT LIKE much faster than LIKE?
  • From: Andrea Arcangeli
• Re: Slow query with joins
  • From: Jim C. Nasby
• Re: Slow query with joins
  • From: Bendik Rognlien Johansen
• Extremely irregular query performance
  • From: Jean-Philippe Côté
• Re: Postgres8.0 planner chooses WRONG plan
  • From: Jim C. Nasby
• Re: NOT LIKE much faster than LIKE?
  • From: Jim C. Nasby
• Re: Improving Inner Join Performance
  • From: Jim C. Nasby
• Re: Index isn't used during a join.
  • From: Michael Fuhr
• Re: Postgres8.0 planner chooses WRONG plan
  • From: Pallav Kalva
• Re: Postgres8.0 planner chooses WRONG plan
  • From: Tom Lane
• Re: Slow query with joins
  • From: Tom Lane
• Re: Index isn't used during a join.
  • From: Tom Lane
• Postgres8.0 planner chooses WRONG plan
  • From: Pallav Kalva
• Postgres8.0 Planner chooses WRONG plan.
  • From: Pallav Kalva
• Re: Index isn't used during a join.
  • From: Robert Creager
• Re: Index isn't used during a join.
  • From: Robert Creager
• Re: [ADMIN] Assimilation of these "versus" and hardware threads
  • From: Josh Berkus
• Slow query with joins
  • From: Bendik Rognlien Johansen
• Re: 500x speed-down: Wrong statistics!
  • From: Alessandro Baretta
• Re: NOT LIKE much faster than LIKE?
  • From: Andrea Arcangeli
• Re: NOT LIKE much faster than LIKE?
  • From: Simon Riggs
• Re: Index isn't used during a join.
  • From: Michael Fuhr
• Re: NOT LIKE much faster than LIKE?
  • From: Andrea Arcangeli
• Re: Index isn't used during a join.
  • From: Michael Fuhr
• Re: help tuning queries on large database
  • From: Ron
• Re: Index isn't used during a join.
  • From: Robert Creager
• Re: Left Join Performance vs Inner Join Performance
  • From: Tom Lane
• Re: How to handle a large DB and simultaneous accesses?
  • From: David Lang
• Re: NOT LIKE much faster than LIKE?
  • From: Tom Lane
• Left Join Performance vs Inner Join Performance
  • From: Dave Dutcher
• Re: help tuning queries on large database
  • From: Mark Lewis
• Re: NOT LIKE much faster than LIKE?
  • From: Simon Riggs
• Re: NOT LIKE much faster than LIKE?
  • From: Tom Lane
• Re: NOT LIKE much faster than LIKE?
  • From: Simon Riggs
• Re: NOT LIKE much faster than LIKE?
  • From: Tom Lane
• Re: NOT LIKE much faster than LIKE?
  • From: Tom Lane
• Re: NOT LIKE much faster than LIKE?
  • From: Andrea Arcangeli
• Re: 500x speed-down: Wrong statistics!
  • From: Tom Lane
• Re: Index isn't used during a join.
  • From: Robert Creager
• Re: NOT LIKE much faster than LIKE?
  • From: Greg Stark
• How to handle a large DB and simultaneous accesses?
  • From: Charles A. Landemaine
• Re: help tuning queries on large database
  • From: Ron
• Re: NOT LIKE much faster than LIKE?
  • From: Matteo Beccati
• Re: 500x speed-down: Wrong statistics!
  • From: Alessandro Baretta
• Re: Index isn't used during a join.
  • From: Michael Fuhr
• Index isn't used during a join.
  • From: Robert Creager
• Re: NOT LIKE much faster than LIKE?
  • From: Andrea Arcangeli
• Re: NOT LIKE much faster than LIKE?
  • From: Stephan Szabo
• Re: NOT LIKE much faster than LIKE?
  • From: Tom Lane
• Re: NOT LIKE much faster than LIKE?
  • From: Andrea Arcangeli
• Re: NOT LIKE much faster than LIKE?
  • From: Christopher Kings-Lynne
• Re: NOT LIKE much faster than LIKE?
  • From: Andrea Arcangeli
• Re: NOT LIKE much faster than LIKE?
  • From: Tom Lane
• NOT LIKE much faster than LIKE?
  • From: Andrea Arcangeli
• Re: [PERFORMANCE] Beetwen text and varchar field
  • From: Bruce Momjian
• Re: help tuning queries on large database
  • From: Luke Lonergan
• Re: help tuning queries on large database
  • From: peter royal
• Re: [ADMIN] Memory Usage Question
  • From: Jim C. Nasby
• Re: help tuning queries on large database
  • From: Luke Lonergan
• Re: 500x speed-down: Wrong query plan?
  • From: Tom Lane
• Memory Usage Question
  • From: Chris Hoover
• Re: 500x speed-down: Wrong query plan?
  • From: Alessandro Baretta
• Re: 500x speed-down: Wrong query plan?
  • From: Tom Lane
• Re: help tuning queries on large database
  • From: peter royal
• >= forces row compare and not index elements compare when possible
  • From: Bernard Dhooghe
• Re: 500x speed-down: Wrong query plan?
  • From: Alessandro Baretta
• Re: Avoiding cartesian product
  • From: Szűcs Gábor
• Re: help tuning queries on large database
  • From: Harry Jackson
• Re: 500x speed-down: Wrong query plan?
  • From: Jaime Casanova
• Re: 500x speed-down: Wrong query plan?
  • From: Matteo Beccati
• Re: help tuning queries on large database
  • From: Kelly Burkhart
• 500x speed-down: Wrong query plan?
  • From: Alessandro Baretta
• Re: [PERFORMANCE] Beetwen text and varchar field
  • From: Steinar H. Gunderson
• [PERFORMANCE] Beetwen text and varchar field
  • From: TNO
• Hanging Query
  • From: vimal . gupta
• Re: Improving Inner Join Performance
  • From: Andy
• Re: help tuning queries on large database
  • From: Ron
• Re: help tuning queries on large database
  • From: Luke Lonergan
• Re: improving write performance for logging
  • From: Michael Stone
• Re: help tuning queries on large database
  • From: David Lang
• Re: help tuning queries on large database
  • From: Harry Jackson
• Re: help tuning queries on large database
  • From: Tom Lane
• help tuning queries on large database
  • From: peter royal
• Re: improving write performance for logging
  • From: Tom Lane
• Re: Slow query. Any way to speed up?
  • From: Tom Lane
• Re: improving write performance for logging
  • From: Ian Westmacott
• Re: Slow query. Any way to speed up?
  • From: Patrick Hatcher
• Re: improving write performance for logging
  • From: Jim C. Nasby
• Re: Improving Inner Join Performance
  • From: Jaime Casanova
• Re: effizient query with jdbc
  • From: Sebastian Hennebrueder
• Re: improving write performance for logging
  • From: Ian Westmacott
• Re: Improving Inner Join Performance
  • From: Andy
• Re: Improving Inner Join Performance
  • From: Pandurangan R S