Postgres Performance Date Index

• Thread Index

• Re: AMD Shanghai versus Intel Nehalem
  • From: Scott Marlowe
• Re: Any better plan for this query?..
  • From: Glenn Maynard
• Re: Any better plan for this query?..
  • From: Robert Haas
• Re: AMD Shanghai versus Intel Nehalem
  • From: Scott Carey
• Re: Any better plan for this query?..
  • From: Robert Haas
• Re: AMD Shanghai versus Intel Nehalem
  • From: Scott Marlowe
• Re: Any better plan for this query?..
  • From: Stephen Frost
• Re: AMD Shanghai versus Intel Nehalem
  • From: Greg Smith
• Re: increase index performance
  • From: Greg Smith
• Re: Any better plan for this query?..
  • From: Aidan Van Dyk
• Re: Any better plan for this query?..
  • From: Joshua D. Drake
• Re: superlative missuse
  • From: David Wilson
• superlative missuse
  • From: Angel Alvarez
• Re: Any better plan for this query?..
  • From: Greg Stark
• Re: Any better plan for this query?..
  • From: Alvaro Herrera
• increase index performance
  • From: Thomas Finneid
• Re: Any better plan for this query?..
  • From: Robert Haas
• AMD Shanghai versus Intel Nehalem
  • From: Scott Marlowe
• Re: Query planner making bad decisions
  • From: Rafael Martinez
• Re: Any better plan for this query?..
  • From: Robert Haas
• Re: Any better plan for this query?..
  • From: Joshua D. Drake
• Re: Any better plan for this query?..
  • From: Scott Carey
• Re: Any better plan for this query?..
  • From: Dimitri Fontaine
• Re: Any better plan for this query?..
  • From: Simon Riggs
• Re: Any better plan for this query?..
  • From: Simon Riggs
• Re: Any better plan for this query?..
  • From: Alvaro Herrera
• Re: Any better plan for this query?..
  • From: Tom Lane
• Re: Any better plan for this query?..
  • From: Dimitri
• Re: Any better plan for this query?..
  • From: Joshua D. Drake
• Re: Any better plan for this query?..
  • From: Dimitri
• Re: Any better plan for this query?..
  • From: Kevin Grittner
• Re: What is the most optimal config parameters to keep stable write TPS ?..
  • From: Dimitri
• Re: Any better plan for this query?..
  • From: Dimitri
• Re: Any better plan for this query?..
  • From: Tom Lane
• Re: Any better plan for this query?..
  • From: Stefan Kaltenbrunner
• Re: Any better plan for this query?..
  • From: Matthew Wakeling
• Re: Any better plan for this query?..
  • From: Simon Riggs
• Re: Any better plan for this query?..
  • From: Matthew Wakeling
• Re: Any better plan for this query?..
  • From: Robert Haas
• Re: Any better plan for this query?..
  • From: Stefan Kaltenbrunner
• Re: What is the most optimal config parameters to keep stable write TPS ?..
  • From: Julian v. Bock
• Re: Any better plan for this query?..
  • From: Dimitri
• Re: Any better plan for this query?..
  • From: Dimitri
• Re: Any better plan for this query?..
  • From: Stefan Kaltenbrunner
• Re: Any better plan for this query?..
  • From: Dimitri
• Re: Query planner making bad decisions
  • From: Cory Coager
• Re: Any better plan for this query?..
  • From: Simon Riggs
• Re: Any better plan for this query?..
  • From: Heikki Linnakangas
• Re: Any better plan for this query?..
  • From: Simon Riggs
• Re: Any better plan for this query?..
  • From: Dimitri
• Re: Any better plan for this query?..
  • From: Simon Riggs
• Re: Any better plan for this query?..
  • From: Dimitri
• Re: Timestamp index not used in some cases
  • From: Scott Marlowe
• Re: What is the most optimal config parameters to keep stable write TPS ?..
  • From: Dimitri
• Re: What is the most optimal config parameters to keep stable write TPS ?..
  • From: Laurent Laborde
• Timestamp index not used in some cases
  • From: Евгений Василев
• Re: Any better plan for this query?..
  • From: Dimitri Fontaine
• Re: Any better plan for this query?..
  • From: Andres Freund
• Re: Any better plan for this query?..
  • From: Dimitri
• Re: Any better plan for this query?..
  • From: Dimitri
• Re: Any better plan for this query?..
  • From: Heikki Linnakangas
• Re: What is the most optimal config parameters to keep stable write TPS ?..
  • From: Scott Marlowe
• Re: What is the most optimal config parameters to keep stable write TPS ?..
  • From: Greg Smith
• Re: Query planner making bad decisions
  • From: Tom Lane
• Re: Any better plan for this query?..
  • From: Alvaro Herrera
• Re: Any better plan for this query?..
  • From: Dimitri
• Re: Any better plan for this query?..
  • From: Dimitri
• Query planner making bad decisions
  • From: Cory Coager
• Re: Any better plan for this query?..
  • From: Aidan Van Dyk
• Re: Any better plan for this query?..
  • From: Simon Riggs
• Re: Any better plan for this query?..
  • From: Simon Riggs
• Re: Any better plan for this query?..
  • From: Merlin Moncure
• Re: What is the most optimal config parameters to keep stable write TPS ?..
  • From: Dimitri
• Re: What is the most optimal config parameters to keep stable write TPS ?..
  • From: Dimitri
• Re: What is the most optimal config parameters to keep stable write TPS ?..
  • From: Scott Marlowe
• Re: What is the most optimal config parameters to keep stable write TPS ?..
  • From: Kevin Grittner
• Re: What is the most optimal config parameters to keep stable write TPS ?..
  • From: Dimitri
• Re: What is the most optimal config parameters to keep stable write TPS ?..
  • From: Kevin Grittner
• Re: What is the most optimal config parameters to keep stable write TPS ?..
  • From: Dimitri
• Re: Any better plan for this query?..
  • From: Dimitri
• Re: What is the most optimal config parameters to keep stable write TPS ?..
  • From: Kevin Grittner
• What is the most optimal config parameters to keep stable write TPS ?..
  • From: Dimitri
• Re: PostgreSQL with PostGIS on embedded hardware
  • From: Stefan Kaltenbrunner
• Re: Any better plan for this query?..
  • From: Tom Lane
• Re: Any better plan for this query?..
  • From: Dimitri
• Re: PostgreSQL with PostGIS on embedded hardware
  • From: PFC
• Re: PostgreSQL with PostGIS on embedded hardware
  • From: Paolo Rizzi
• Reminder: Please Respond to Rohan's Invitation
  • From: Rohan Pethkar
• Re: Bad Plan for Questionnaire-Type Query
  • From: David Blewett
• Re: Bad Plan for Questionnaire-Type Query
  • From: Tom Lane
• Re: Bad Plan for Questionnaire-Type Query
  • From: David Blewett
• Re: Slow select performance despite seemingly reasonable query plan
  • From: Laurent Wandrebeck
• Re: Bad Plan for Questionnaire-Type Query
  • From: Tom Lane
• Re: Transparent table partitioning in future version of PG?
  • From: Craig Ringer
• Re: PostgreSQL with PostGIS on embedded hardware
  • From: Tom Lane
• Re: Bad Plan for Questionnaire-Type Query
  • From: Tom Lane
• Re: PostgreSQL with PostGIS on embedded hardware
  • From: Paolo Rizzi
• Re: PostgreSQL with PostGIS on embedded hardware
  • From: PFC
• Re: PostgreSQL with PostGIS on embedded hardware
  • From: Paolo Rizzi
• Re: Transparent table partitioning in future version of PG?
  • From: Tom Lane
• Re: Transparent table partitioning in future version of PG?
  • From: Robert Haas
• Re: Transparent table partitioning in future version of PG?
  • From: Scott Carey
• Re: PostgreSQL with PostGIS on embedded hardware
  • From: Fernando Hevia
• Re: Transparent table partitioning in future version of PG?
  • From: david
• Re: PostgreSQL with PostGIS on embedded hardware
  • From: Paolo Rizzi
• Re: Transparent table partitioning in future version of PG?
  • From: Scott Carey
• Re: PostgreSQL with PostGIS on embedded hardware
  • From: Joshua D. Drake
• Re: Transparent table partitioning in future version of PG?
  • From: Robert Haas
• Re: Statistics use with functions
  • From: Tom Lane
• PostgreSQL with PostGIS on embedded hardware
  • From: Paolo Rizzi
• Re: Statistics use with functions
  • From: Matthew Wakeling
• Re: Statistics use with functions
  • From: Tom Lane
• Statistics use with functions
  • From: Matthew Wakeling
• Re: Indexes not used in DELETE
  • From: Viktor Rosenfeld
• Rohan Pethkar sent you a Friend Request on Yaari
  • From: Rohan Pethkar
• Re: Transparent table partitioning in future version of PG?
  • From: david
• Re: Transparent table partitioning in future version of PG?
  • From: Robert Haas
• Re: Indexes not used in DELETE
  • From: Tom Lane
• Re: Bad Plan for Questionnaire-Type Query
  • From: David Blewett
• Indexes not used in DELETE
  • From: Viktor Rosenfeld
• Re: Bad Plan for Questionnaire-Type Query
  • From: Tom Lane
• Re: Bad Plan for Questionnaire-Type Query
  • From: David Blewett
• Re: Bad Plan for Questionnaire-Type Query
  • From: Tom Lane
• Re: Any better plan for this query?..
  • From: Simon Riggs
• Re: Any better plan for this query?..
  • From: Dimitri
• Re: Transparent table partitioning in future version of PG?
  • From: Scott Carey
• Re: Bad Plan for Questionnaire-Type Query
  • From: David Blewett
• Bad Plan for Questionnaire-Type Query
  • From: David Blewett
• Re: Slow select performance despite seemingly reasonable query plan
  • From: Nikolas Everett
• Re: Any better plan for this query?..
  • From: Alvaro Herrera
• Re: Slow select performance despite seemingly reasonable query plan
  • From: Matthew Wakeling
• Re: Slow select performance despite seemingly reasonable query plan
  • From: Nikolas Everett
• Re: Slow select performance despite seemingly reasonable query plan
  • From: David Brain
• Re: Slow select performance despite seemingly reasonable query plan
  • From: Matthew Wakeling
• Re: Slow select performance despite seemingly reasonable query plan
  • From: David Brain
• Re: Slow select performance despite seemingly reasonable query plan
  • From: Scott Mead
• Slow select performance despite seemingly reasonable query plan
  • From: David Brain
• Re: GiST index performance
  • From: Matthew Wakeling
• Re: Any better plan for this query?..
  • From: Simon Riggs
• Re: Any better plan for this query?..
  • From: Gregory Stark
• Re: Any better plan for this query?..
  • From: Merlin Moncure
• Re: GiST index performance
  • From: Oleg Bartunov
• Re: Transparent table partitioning in future version of PG?
  • From: Simon Riggs
• Re: Any better plan for this query?..
  • From: Dimitri
• Re: Any better plan for this query?..
  • From: Dimitri
• Re: Transparent table partitioning in future version of PG?
  • From: Craig Ringer
• Re: Transparent table partitioning in future version of PG?
  • From: Alvaro Herrera
• Re: Transparent table partitioning in future version of PG?
  • From: Tom Lane
• Re: Transparent table partitioning in future version of PG?
  • From: Simon Riggs
• Re: GiST index performance
  • From: Tom Lane
• Re: Transparent table partitioning in future version of PG?
  • From: Tom Lane
• Re: Any better plan for this query?..
  • From: Simon Riggs
• Re: Transparent table partitioning in future version of PG?
  • From: Simon Riggs
• Re: Any better plan for this query?..
  • From: Kenneth Marshall
• Re: Any better plan for this query?..
  • From: Dimitri
• Re: Any better plan for this query?..
  • From: Dimitri
• Re: Any better plan for this query?..
  • From: Kenneth Marshall
• Re: Any better plan for this query?..
  • From: Dimitri
• Re: Any better plan for this query?..
  • From: Matthew Wakeling
• Re: Any better plan for this query?..
  • From: Kenneth Marshall
• Re: Any better plan for this query?..
  • From: Craig Ringer
• Re: Any better plan for this query?..
  • From: Dimitri
• Re: Any better plan for this query?..
  • From: Ries van Twisk
• Re: Any better plan for this query?..
  • From: Kenneth Marshall
• Re: Any better plan for this query?..
  • From: Kenneth Marshall
• Re: Any better plan for this query?..
  • From: Richard Huxton
• Re: Any better plan for this query?..
  • From: Dimitri
• Re: Any better plan for this query?..
  • From: Albe Laurenz
• Re: Any better plan for this query?..
  • From: Merlin Moncure
• Re: Any better plan for this query?..
  • From: Merlin Moncure
• Re: Any better plan for this query?..
  • From: Matthew Wakeling
• Re: Any better plan for this query?..
  • From: Richard Huxton
• Re: Any better plan for this query?..
  • From: Richard Huxton
• Re: Any better plan for this query?..
  • From: Dimitri
• Re: Any better plan for this query?..
  • From: Dimitri
• Re: Any better plan for this query?..
  • From: Dimitri
• Re: Any better plan for this query?..
  • From: Chris
• Re: Any better plan for this query?..
  • From: Heikki Linnakangas
• Re: Any better plan for this query?..
  • From: Dimitri
• Re: Any better plan for this query?..
  • From: Craig Ringer
• Any better plan for this query?..
  • From: Dimitri
• Re: Limit I/O bandwidth of a certain backend
  • From: Greg Smith
• Re: Limit I/O bandwidth of a certain backend
  • From: Bryan Murphy
• Re: [HACKERS] high shared buffer and swap
  • From: Matthew Wakeling
• Re: [HACKERS] high shared buffer and swap
  • From: Laurent Laborde
• Re: [HACKERS] high shared buffer and swap
  • From: PFC
• Limit I/O bandwidth of a certain backend
  • From: Vlad Arkhipov
• Re: high shared buffer and swap
  • From: Scott Marlowe
• Re: [HACKERS] high shared buffer and swap
  • From: Martijn van Oosterhout
• Re: high shared buffer and swap
  • From: Greg Stark
• high shared buffer and swap
  • From: Laurent Laborde
• Re: performance for high-volume log insertion
  • From: Glenn Maynard
• Re: performance for high-volume log insertion
  • From: david
• Re: performance for high-volume log insertion
  • From: PFC
• Re: Transparent table partitioning in future version of PG?
  • From: Scott Carey
• Re: Many left outer joins with limit performance
  • From: Tom Lane
• Re: bad plan and LIMIT
  • From: James Nelson
• Re: Transparent table partitioning in future version of PG?
  • From: Robert Haas
• Re: bad plan and LIMIT
  • From: James Nelson
• Re: bad plan and LIMIT
  • From: James Nelson
• Re: bad plan and LIMIT
  • From: Tom Lane
• Transparent table partitioning in future version of PG?
  • From: henk de wit
• Many left outer joins with limit performance
  • From: Gerhard Wiesinger
• Re: bad plan and LIMIT
  • From: Grzegorz Jaśkiewicz
• Re: bad plan and LIMIT
  • From: Grzegorz Jaśkiewicz
• Re: bad plan and LIMIT
  • From: Adam Ruth
• bad plan and LIMIT
  • From: James Nelson
• Re: partition question for new server setup
  • From: Whit Armstrong
• Re: partition question for new server setup
  • From: Whit Armstrong
• Re: partition question for new server setup
  • From: Scott Carey
• Re: partition question for new server setup
  • From: Scott Carey
• Re: partition question for new server setup
  • From: Scott Carey
• Re: partition question for new server setup
  • From: Scott Marlowe
• Re: partition question for new server setup
  • From: Whit Armstrong
• Re: partition question for new server setup
  • From: Whit Armstrong
• Re: partition question for new server setup
  • From: Scott Carey
• Re: partition question for new server setup
  • From: Scott Carey
• Re: pg_lock_status() performance
  • From: Tom Lane
• Re: pg_lock_status() performance
  • From: Merlin Moncure
• Re: pg_lock_status() performance
  • From: Merlin Moncure
• Re: pg_lock_status() performance
  • From: Tom Lane
• Re: partition question for new server setup
  • From: Scott Marlowe
• Re: partition question for new server setup
  • From: Scott Marlowe
• Re: partition question for new server setup
  • From: Whit Armstrong
• Re: partition question for new server setup
  • From: Scott Marlowe
• Re: partition question for new server setup
  • From: Kevin Grittner
• Re: partition question for new server setup
  • From: Whit Armstrong
• Re: partition question for new server setup
  • From: Kenneth Marshall
• Re: partition question for new server setup
  • From: Kevin Grittner
• Re: partition question for new server setup
  • From: Craig James
• Re: partition question for new server setup
  • From: Alan Hodgson
• Re: partition question for new server setup
  • From: Craig James
• Re: partition question for new server setup
  • From: Kenneth Marshall
• Re: partition question for new server setup
  • From: Scott Marlowe
• pg_lock_status() performance
  • From: Merlin Moncure
• Re: partition question for new server setup
  • From: Whit Armstrong
• Re: partition question for new server setup
  • From: Scott Marlowe
• partition question for new server setup
  • From: Whit Armstrong
• any interest of changing the page size ?
  • From: Laurent Laborde
• Re: plpgsql function running long, but resources consumption is very low
  • From: Scott Carey
• Re: Using IOZone to simulate DB access patterns
  • From: Laurent Laborde
• Re: plpgsql function running long, but resources consumption is very low
  • From: Pavel Stehule
• plpgsql function running long, but resources consumption is very low
  • From: Wojtek
• Re: performance for high-volume log insertion
  • From: david
• Re: performance for high-volume log insertion
  • From: Scott Marlowe
• Re: performance for high-volume log insertion
  • From: Kris Jurka
• Re: performance for high-volume log insertion
  • From: Scott Marlowe
• Re: Using IOZone to simulate DB access patterns
  • From: Mark Wong
• Re: Using IOZone to simulate DB access patterns
  • From: Mark Wong
• Re: performance for high-volume log insertion
  • From: Thomas
• Re: performance for high-volume log insertion
  • From: Kris Jurka
• [no subject]
  • From: Adam Ruth
• Re: performance for high-volume log insertion
  • From: Thomas Kellerer
• Re: WHERE condition not being pushed down to union parts
  • From: Tom Lane
• Re: WHERE condition not being pushed down to union parts
  • From: John L. Clark
• Re: performance for high-volume log insertion
  • From: Stephen Frost
• Re: performance for high-volume log insertion
  • From: Stephen Frost
• Re: performance for high-volume log insertion
  • From: david
• Re: performance for high-volume log insertion
  • From: Glenn Maynard
• Re: performance for high-volume log insertion
  • From: Stephen Frost
• Re: performance for high-volume log insertion
  • From: Stephen Frost
• Re: performance for high-volume log insertion
  • From: david
• Re: performance for high-volume log insertion
  • From: Glenn Maynard
• Re: performance for high-volume log insertion
  • From: Stephen Frost
• Re: performance for high-volume log insertion
  • From: Glenn Maynard
• Re: performance for high-volume log insertion
  • From: Glenn Maynard
• Re: performance for high-volume log insertion
  • From: Joshua D. Drake
• Re: performance for high-volume log insertion
  • From: Glenn Maynard
• Re: performance for high-volume log insertion
  • From: James Mansion
• Re: performance for high-volume log insertion
  • From: Tom Lane
• Re: performance for high-volume log insertion
  • From: Stephen Frost
• Re: performance for high-volume log insertion
  • From: david
• Re: performance for high-volume log insertion
  • From: Glenn Maynard
• Re: GiST index performance
  • From: Matthew Wakeling
• Re: performance for high-volume log insertion
  • From: Simon Riggs
• Re: GiST index performance
  • From: Matthew Wakeling
• Re: performance for high-volume log insertion
  • From: Stephen Frost
• Re: performance for high-volume log insertion
  • From: Stephen Frost
• Re: probelm with alter table add constraint......
  • From: roopabenzer
• Re: performance for high-volume log insertion
  • From: James Mansion
• Re: performance for high-volume log insertion
  • From: Robert Haas
• Re: performance for high-volume log insertion
  • From: david
• Re: performance for high-volume log insertion
  • From: Greg Smith
• Re: WHERE condition not being pushed down to union parts
  • From: Tom Lane
• Re: performance for high-volume log insertion
  • From: Stephen Frost
• Re: performance for high-volume log insertion
  • From: James Mansion
• Re: performance for high-volume log insertion
  • From: Stephen Frost
• Re: performance for high-volume log insertion
  • From: Stephen Frost
• Re: performance for high-volume log insertion
  • From: david
• Re: performance for high-volume log insertion
  • From: david
• Re: performance for high-volume log insertion
  • From: Kenneth Marshall
• Re: WHERE condition not being pushed down to union parts
  • From: John L. Clark
• Re: performance for high-volume log insertion
  • From: david
• Re: performance for high-volume log insertion
  • From: Stephen Frost
• Re: performance for high-volume log insertion
  • From: Greg Smith
• Re: performance for high-volume log insertion
  • From: david
• Re: performance for high-volume log insertion
  • From: Stephen Frost
• Re: performance for high-volume log insertion
  • From: Ben Chobot
• Re: SQL With Dates
  • From: Robert Haas
• Re: performance for high-volume log insertion
  • From: Kenneth Marshall
• Re: performance for high-volume log insertion
  • From: david
• Re: WHERE condition not being pushed down to union parts
  • From: Tom Lane
• Re: WHERE condition not being pushed down to union parts
  • From: John L. Clark
• Re: WHERE condition not being pushed down to union parts
  • From: Tom Lane
• WHERE condition not being pushed down to union parts
  • From: John L. Clark
• Re: performance for high-volume log insertion
  • From: Kenneth Marshall
• Re: GiST index performance
  • From: Matthew Wakeling
• Re: performance for high-volume log insertion
  • From: Richard Huxton
• Re: performance for high-volume log insertion
  • From: david
• Re: performance for high-volume log insertion
  • From: david
• Re: performance for high-volume log insertion
  • From: Stephen Frost
• Re: performance for high-volume log insertion
  • From: Stephen Frost
• Re: performance for high-volume log insertion
  • From: Stephen Frost
• Re: performance for high-volume log insertion
  • From: david
• Re: performance for high-volume log insertion
  • From: david
• Re: performance for high-volume log insertion
  • From: david
• Re: performance for high-volume log insertion
  • From: Stephen Frost
• Re: performance for high-volume log insertion
  • From: david
• Re: performance for high-volume log insertion
  • From: Stephen Frost
• Re: performance for high-volume log insertion
  • From: Greg Smith
• Re: performance for high-volume log insertion
  • From: Stephen Frost
• Re: performance for high-volume log insertion
  • From: david
• Re: performance for high-volume log insertion
  • From: Stephen Frost
• performance for high-volume log insertion
  • From: david
• Re: SQL With Dates
  • From: Mark Lewis
• Re: SQL With Dates
  • From: Scott Marlowe
• Re: SQL With Dates
  • From: Rafael Domiciano
• Re: GiST index performance
  • From: Tom Lane
• Re: SQL With Dates
  • From: Grzegorz Jaśkiewicz
• Re: GiST index performance
  • From: Matthew Wakeling
• SQL With Dates
  • From: Rafael Domiciano
• Re: No hash join across partitioned tables?
  • From: Tom Lane
• Re: stats are way off on 8.4 b1
  • From: Grzegorz Jaśkiewicz
• Re: stats are way off on 8.4 b1
  • From: Heikki Linnakangas
• Re: stats are way off on 8.4 b1
  • From: Grzegorz Jaśkiewicz
• Re: stats are way off on 8.4 b1
  • From: Tom Lane
• stats are way off on 8.4 b1
  • From: Grzegorz Jaśkiewicz
• Re: GiST index performance
  • From: Matthew Wakeling
• Re: No hash join across partitioned tables?
  • From: Kris Jurka
• Re: No hash join across partitioned tables?
  • From: Kris Jurka
• Re: No hash join across partitioned tables?
  • From: Tom Lane
• Re: No hash join across partitioned tables?
  • From: Tom Lane
• Optimizer's issue
  • From: Vlad Arkhipov
• Re: GiST index performance
  • From: Craig Ringer
• Re: No hash join across partitioned tables?
  • From: Kris Jurka
• Re: No hash join across partitioned tables?
  • From: Kris Jurka
• Re: No hash join across partitioned tables?
  • From: Tom Lane
• No hash join across partitioned tables?
  • From: Kris Jurka
• Re: GiST index performance
  • From: Matthew Wakeling
• Re: GiST index performance
  • From: Tom Lane
• Re: GiST index performance
  • From: Matthew Wakeling
• Re: GiST index performance
  • From: Tom Lane
• Re: GiST index performance
  • From: dforum
• Re: GiST index performance
  • From: Matthew Wakeling
• Re: GiST index performance
  • From: Tom Lane
• Re: GiST index performance
  • From: Matthew Wakeling
• Re: GiST index performance
  • From: Kevin Grittner
• GiST index performance
  • From: Matthew Wakeling
• Re: Really dumb planner decision
  • From: Tom Lane
• Re: Shouldn't the planner have a higher cost for reverse index scans?
  • From: Tom Lane
• Re: Really dumb planner decision
  • From: Matthew Wakeling
• Re: Shouldn't the planner have a higher cost for reverse index scans?
  • From: Lists
• Re: Really dumb planner decision
  • From: Robert Haas
• Re: Shouldn't the planner have a higher cost for reverse index scans?
  • From: Tom Lane
• Re: Shouldn't the planner have a higher cost for reverse index scans?
  • From: Tom Lane
• Re: Really dumb planner decision
  • From: Merlin Moncure
• Re: Really dumb planner decision
  • From: Kevin Grittner
• Re: Really dumb planner decision
  • From: Tom Lane
• Re: Really dumb planner decision
  • From: Merlin Moncure
• Re: Shouldn't the planner have a higher cost for reverse index scans?
  • From: Merlin Moncure
• Re: Really dumb planner decision
  • From: Matthew Wakeling
• Re: Really dumb planner decision
  • From: Robert Haas
• Re: Really dumb planner decision
  • From: Matthew Wakeling
• Re: Really dumb planner decision
  • From: Matthew Wakeling
• Re: Really dumb planner decision
  • From: Grzegorz Jaśkiewicz
• Re: Really dumb planner decision
  • From: Grzegorz Jaśkiewicz
• Really dumb planner decision
  • From: Matthew Wakeling
• Re: Shouldn't the planner have a higher cost for reverse index scans?
  • From: Grzegorz Jaśkiewicz
• Re: Shouldn't the planner have a higher cost for reverse index scans?
  • From: Lists
• Re: error updating a very large table
  • From: Simon Riggs
• Re: error updating a very large table
  • From: Tom Lane
• Re: INSERT times - same storage space but more fields -> much slower inserts
  • From: Matthew Wakeling
• Re: INSERT times - same storage space but more fields -> much slower inserts
  • From: Matthew Wakeling
• need information
  • From: Peeyush
• Re: error updating a very large table
  • From: Grzegorz Jaśkiewicz
• Re: INSERT times - same storage space but more fields -> much slower inserts
  • From: Stephen Frost
• error updating a very large table
  • From: Brian Cox
• Re: INSERT times - same storage space but more fields -> much slower inserts
  • From: Tom Lane
• Re: INSERT times - same storage space but more fields -> much slower inserts
  • From: Craig Ringer
• Re: INSERT times - same storage space but more fields -> much slower inserts
  • From: Stephen Frost
• Re: INSERT times - same storage space but more fields -> much slower inserts
  • From: Matthew Wakeling
• Re: difficulties with time based queries
  • From: Nikolas Everett
• Re: INSERT times - same storage space but more fields -> much slower inserts
  • From: Stephen Frost
• Re: Nested query performance issue
  • From: Merlin Moncure
• Re: Nested query performance issue
  • From: Glenn Maynard
• Re: Shouldn't the planner have a higher cost for reverse index scans?
  • From: Matthew Wakeling
• Re: Nested query performance issue
  • From: Matthew Wakeling
• Re: difficulties with time based queries
  • From: PFC
• INSERT times - same storage space but more fields -> much slower inserts
  • From: Craig Ringer
• Re: Postgres 8.x on Windows Server in production
  • From: Justin Pitts
• Re: Postgres 8.x on Windows Server in production
  • From: Grzegorz Jaśkiewicz
• Re: Postgres 8.x on Windows Server in production
  • From: Scott Marlowe
• Re: linux deadline i/o elevator tuning
  • From: Kevin Grittner
• Re: linux deadline i/o elevator tuning
  • From: Jeff
• Re: Postgres 8.x on Windows Server in production
  • From: Ognjen Blagojevic
• Re: 2.6.26 kernel and PostgreSQL
  • From: Glyn Astill
• Re: 2.6.26 kernel and PostgreSQL
  • From: Greg Smith
• Re: Postgres 8.x on Windows Server in production
  • From: Scott Marlowe
• Re: Postgres 8.x on Windows Server in production
  • From: Rainer Mager
• Re: Postgres 8.x on Windows Server in production
  • From: Scott Marlowe
• Re: Postgres 8.x on Windows Server in production
  • From: Rainer Mager
• Re: Using IOZone to simulate DB access patterns
  • From: Scott Carey
• Re: Using IOZone to simulate DB access patterns
  • From: Mark Wong
• Re: Using IOZone to simulate DB access patterns
  • From: M. Edward (Ed) Borasky
• Re: 2.6.26 kernel and PostgreSQL
  • From: Glyn Astill
• Re: Postgres 8.x on Windows Server in production
  • From: Grzegorz Jaśkiewicz
• Re: 2.6.26 kernel and PostgreSQL
  • From: Kevin Grittner
• 2.6.26 kernel and PostgreSQL
  • From: Glyn Astill
• Re: determining the locks that will be held by a query
  • From: Kevin Grittner
• Re: Using IOZone to simulate DB access patterns
  • From: Greg Smith
• determining the locks that will be held by a query
  • From: Brian Cox
• Re: Using IOZone to simulate DB access patterns
  • From: Scott Carey
• Re: Postgres 8.x on Windows Server in production
  • From: Josh Berkus
• Re: Using IOZone to simulate DB access patterns
  • From: Greg Smith
• Re: plpgsql arrays
  • From: Tom Lane
• Re: Shouldn't the planner have a higher cost for reverse index scans?
  • From: Josh Berkus
• Re: Using IOZone to simulate DB access patterns
  • From: Scott Carey
• Re: Using IOZone to simulate DB access patterns
  • From: Josh Berkus
• Re: Shouldn't the planner have a higher cost for reverse index scans?
  • From: Tom Lane
• Re: Using IOZone to simulate DB access patterns
  • From: Josh Berkus
• Re: Using IOZone to simulate DB access patterns
  • From: Scott Carey
• Re: Using IOZone to simulate DB access patterns
  • From: Josh Berkus
• Re: Shouldn't the planner have a higher cost for reverse index scans?
  • From: Josh Berkus
• Re: Using IOZone to simulate DB access patterns
  • From: Joshua D. Drake
• Re: Shouldn't the planner have a higher cost for reverse index scans?
  • From: Tom Lane
• Re: Nested query performance issue
  • From: Tom Lane
• Postgres 8.x on Windows Server in production
  • From: Ognjen Blagojevic
• Re: linux deadline i/o elevator tuning
  • From: Albe Laurenz *EXTERN*
• Shouldn't the planner have a higher cost for reverse index scans?
  • From: Josh Berkus
• Re: Using IOZone to simulate DB access patterns
  • From: Mark Kirkwood
• Re: Nested query performance issue
  • From: Glenn Maynard
• Re: Using IOZone to simulate DB access patterns
  • From: Josh Berkus
• Re: difficulties with time based queries
  • From: Tom Lane
• Re: difficulties with time based queries
  • From: Rainer Mager
• Re: Nested query performance issue
  • From: Greg Smith
• Re: Nested query performance issue
  • From: Glenn Maynard
• Re: Nested query performance issue
  • From: Glenn Maynard
• Re: linux deadline i/o elevator tuning
  • From: Scott Carey
• Re: linux deadline i/o elevator tuning
  • From: Mark Wong
• Re: linux deadline i/o elevator tuning
  • From: Kevin Grittner
• Re: linux deadline i/o elevator tuning
  • From: Mark Wong
• Re: linux deadline i/o elevator tuning
  • From: Arjen van der Meijden
• Re: linux deadline i/o elevator tuning
  • From: Grzegorz Jaśkiewicz
• Re: linux deadline i/o elevator tuning
  • From: Matthew Wakeling
• Re: linux deadline i/o elevator tuning
  • From: Kevin Grittner
• Re: linux deadline i/o elevator tuning
  • From: Kevin Grittner
• Re: linux deadline i/o elevator tuning
  • From: Grzegorz Jaśkiewicz
• Re: linux deadline i/o elevator tuning
  • From: Matthew Wakeling
• Re: linux deadline i/o elevator tuning
  • From: Grzegorz Jaśkiewicz
• Re: linux deadline i/o elevator tuning
  • From: Kevin Grittner
• linux deadline i/o elevator tuning
  • From: Mark Wong
• Re: Best replication solution?
  • From: Jeff
• Re: Nested query performance issue
  • From: Heikki Linnakangas
• Re: Nested query performance issue
  • From: Віталій Тимчишин
• Re: difficulties with time based queries
  • From: Rainer Mager
• Re: Nested query performance issue
  • From: Glenn Maynard
• Re: Nested query performance issue
  • From: Віталій Тимчишин
• Nested query performance issue
  • From: Glenn Maynard
• Re: Best replication solution?
  • From: Dimitri Fontaine
• Re: Best replication solution?
  • From: Jeff
• Re: bad query plans for ~ "^string" (and like "string%") (8.3.6)
  • From: Tom Lane
• Re: bad query plans for ~ "^string" (and like "string%") (8.3.6)
  • From: Robert Haas
• Re: bad query plans for ~ "^string" (and like "string%") (8.3.6)
  • From: Marinos Yannikos
• bad query plans for ~ "^string" (and like "string%") (8.3.6)
  • From: Marinos Yannikos
• Re: Best replication solution?
  • From: Marinos Yannikos
• Re: plpgsql arrays
  • From: Matthew Wakeling
• Re: Best replication solution?
  • From: Mark Kirkwood
• Re: 8.4 Performance improvements: was Re: Proposal of tunable fix for scalability of 8.4
  • From: Bruce Momjian
• Re: plpgsql arrays
  • From: Tom Lane
• Re: plpgsql arrays
  • From: Merlin Moncure
• determining the locks that will be held by a query
  • From: Brian Cox
• Re: Best replication solution?
  • From: Andrew Sullivan
• Re: plpgsql arrays
  • From: Matthew Wakeling
• Re: Best replication solution?
  • From: Andrew Sullivan
• Re: plpgsql arrays
  • From: Tom Lane
• Re: plpgsql arrays
  • From: justin
• Re: plpgsql arrays
  • From: Matthew Wakeling
• Re: plpgsql arrays
  • From: justin
• Re: plpgsql arrays
  • From: Matthew Wakeling
• Re: Best replication solution?
  • From: Mark Kirkwood
• Re: Best replication solution?
  • From: Ivan Voras
• Re: Best replication solution?
  • From: Dimitri Fontaine
• Re: Best replication solution?
  • From: Lists
• Re: Best replication solution?
  • From: Lists
• Re: Forcing seq_scan off for large table joined with tiny table yeilds improved performance
  • From: Scott Marlowe
• Re: Forcing seq_scan off for large table joined with tiny table yeilds improved performance
  • From: Mario Splivalo
• Re: Forcing seq_scan off for large table joined with tiny table yeilds improved performance
  • From: Scott Marlowe
• Re: Forcing seq_scan off for large table joined with tiny table yeilds improved performance
  • From: Mario Splivalo
• Re: plpgsql arrays
  • From: Robert Haas
• Re: Forcing seq_scan off for large table joined with tiny table yeilds improved performance
  • From: Scott Marlowe
• Re: probelm with alter table add constraint......
  • From: Tom Lane
• Re: plpgsql arrays
  • From: Matthew Wakeling
• Re: Best replication solution?
  • From: Andrew Sullivan
• Re: difficulties with time based queries
  • From: Matthew Wakeling
• Re: Forcing seq_scan off for large table joined with tiny table yeilds improved performance
  • From: Mario Splivalo
• Re: plpgsql arrays
  • From: Matthew Wakeling
• Re: probelm with alter table add constraint......
  • From: Albe Laurenz
• Re: probelm with alter table add constraint......
  • From: Robert Haas
• Re: difficulties with time based queries
  • From: Robert Haas
• Re: Best replication solution?
  • From: Heikki Linnakangas
• probelm with alter table add constraint......
  • From: roopasatish
• Re: difficulties with time based queries
  • From: Rainer Mager
• Re: Best replication solution?
  • From: Greg Sabino Mullane
• Re: difficulties with time based queries
  • From: Tom Lane
• Re: difficulties with time based queries
  • From: Rainer Mager
• Re: difficulties with time based queries
  • From: Tom Lane
• Re: difficulties with time based queries
  • From: PFC
• Re: difficulties with time based queries
  • From: David Wilson
• difficulties with time based queries
  • From: Rainer Mager
• Re: Best replication solution?
  • From: Lists
• Best replication solution?
  • From: Lists
• Re: Question on pgbench output
  • From: Tom Lane
• Re: Question on pgbench output
  • From: David Kerr
• Re: Question on pgbench output
  • From: Tom Lane
• Re: Question on pgbench output
  • From: Simon Riggs
• Re: Question on pgbench output
  • From: David Kerr
• Re: Strange behavior: pgbench and new Linux kernels
  • From: Greg Smith
• Re: Strange behavior: pgbench and new Linux kernels
  • From: Josh Berkus
• Re: Strange behavior: pgbench and new Linux kernels
  • From: Greg Smith
• Re: Using IOZone to simulate DB access patterns
  • From: henk de wit
• Re: Using IOZone to simulate DB access patterns
  • From: Jesper Krogh
• Re: Using IOZone to simulate DB access patterns
  • From: henk de wit
• Re: Raid 10 chunksize
  • From: Scott Carey
• Re: Question on pgbench output
  • From: Greg Smith
• Re: Raid 10 chunksize
  • From: Greg Smith
• Re: Raid 10 chunksize
  • From: david
• Re: Using IOZone to simulate DB access patterns
  • From: Josh Berkus
• Re: Question on pgbench output
  • From: David Kerr
• Re: Question on pgbench output
  • From: David Kerr
• Using IOZone to simulate DB access patterns
  • From: Josh Berkus
• Re: Question on pgbench output
  • From: Tom Lane
• Re: Question on pgbench output
  • From: Tom Lane
• Re: Question on pgbench output
  • From: Greg Smith
• Re: Question on pgbench output
  • From: Scott Marlowe
• Re: Question on pgbench output
  • From: David Kerr
• Re: Question on pgbench output
  • From: Tom Lane
• Question on pgbench output
  • From: David Kerr
• Re: plpgsql arrays
  • From: Nathan Boley
• Re: plpgsql arrays
  • From: Tom Lane
• Re: plpgsql arrays
  • From: Alvaro Herrera
• Re: plpgsql arrays
  • From: Simon Riggs
• Re: Rewriting using rules for performance
  • From: Merlin Moncure
• Re: Rewriting using rules for performance
  • From: Merlin Moncure
• Re: plpgsql arrays
  • From: Merlin Moncure
• Re: plpgsql arrays
  • From: Matthew Wakeling
• Re: plpgsql arrays
  • From: Merlin Moncure
• Re: plpgsql arrays
  • From: Merlin Moncure
• Re: plpgsql arrays
  • From: Matthew Wakeling
• Re: plpgsql arrays
  • From: Tom Lane
• Re: plpgsql arrays
  • From: Matthew Wakeling
• Re: plpgsql arrays
  • From: Matthew Wakeling
• Re: plpgsql arrays
  • From: Tom Lane
• Re: plpgsql arrays
  • From: Matthew Wakeling
• Re: plpgsql arrays
  • From: Tom Lane
• Re: plpgsql arrays
  • From: Tom Lane
• Re: plpgsql arrays
  • From: Matthew Wakeling
• Re: Rewriting using rules for performance
  • From: Matthew Wakeling
• Re: plpgsql arrays
  • From: Robert Haas
• Re: Rewriting using rules for performance
  • From: Robert Haas
• plpgsql arrays
  • From: Matthew Wakeling
• Rewriting using rules for performance
  • From: Matthew Wakeling
• Re: Raid 10 chunksize
  • From: Greg Smith
• Re: Raid 10 chunksize
  • From: Greg Smith
• Re: Raid 10 chunksize
  • From: Greg Smith
• Re: Raid 10 chunksize
  • From: Mark Kirkwood
• Re: Raid 10 chunksize
  • From: Hannes Dorbath
• Re: Raid 10 chunksize
  • From: Ron Mayer
• Re: 8.4 Performance improvements: was Re: Proposal of tunable fix for scalability of 8.4
  • From: Bruce Momjian
• Re: Raid 10 chunksize
  • From: Scott Carey
• Re: Raid 10 chunksize
  • From: Scott Carey
• Re: Raid 10 chunksize
  • From: Merlin Moncure
• Re: Raid 10 chunksize
  • From: Scott Carey
• Re: How to get parallel restore in PG 8.4 to work?
  • From: henk de wit
• Re: Raid 10 chunksize
  • From: James Mansion
• Re: Raid 10 chunksize
  • From: Merlin Moncure
• Re: Very specialised query
  • From: Craig Ringer
• Re: Very specialised query
  • From: Matthew Wakeling
• Re: Raid 10 chunksize
  • From: Greg Smith
• Re: Raid 10 chunksize
  • From: Mark Kirkwood
• Re: Raid 10 chunksize
  • From: Mark Kirkwood
• Re: Raid 10 chunksize
  • From: Scott Marlowe
• Re: Raid 10 chunksize
  • From: david
• Re: Raid 10 chunksize
  • From: Scott Carey
• Re: Raid 10 chunksize
  • From: Scott Carey
• Re: Raid 10 chunksize
  • From: Scott Carey
• Re: Raid 10 chunksize
  • From: Scott Carey
• Re: self join revisited
  • From: Robert Haas
• Re: Raid 10 chunksize
  • From: david
• Re: Raid 10 chunksize
  • From: Stef Telford
• Re: Raid 10 chunksize
  • From: david
• Re: Raid 10 chunksize
  • From: Stef Telford
• Re: self join revisited
  • From: Rikard Pavelic
• Re: Very specialised query
  • From: Matthew Wakeling
• Re: Raid 10 chunksize
  • From: Scott Marlowe
• Re: Raid 10 chunksize
  • From: Matthew Wakeling
• Re: Raid 10 chunksize
  • From: Greg Smith
• Re: Very specialised query
  • From: Matthew Wakeling
• Re: self join revisited
  • From: Tom Lane
• Re: Raid 10 chunksize
  • From: Stef Telford
• Re: Very specialised query
  • From: Matthew Wakeling
• Re: Raid 10 chunksize
  • From: Scott Marlowe
• Re: Raid 10 chunksize
  • From: Matthew Wakeling
• Re: Raid 10 chunksize
  • From: Scott Marlowe
• Re: Raid 10 chunksize
  • From: Matthew Wakeling
• Re: Raid 10 chunksize
  • From: Stef Telford
• Re: self join revisited
  • From: Matthew Wakeling
• Re: Raid 10 chunksize
  • From: Scott Marlowe
• self join revisited
  • From: Rikard Pavelic
• Re: Raid 10 chunksize
  • From: Stef Telford
• Re: Raid 10 chunksize
  • From: Greg Smith
• Re: Raid 10 chunksize
  • From: Stef Telford
• Re: PostgreSQL
  • From: Robert Haas
• Re: How to get parallel restore in PG 8.4 to work?
  • From: Tom Lane
• Re: How to get parallel restore in PG 8.4 to work?
  • From: henk de wit
• PostgreSQL
  • From: Mahu Vasile
• Re: Raid 10 chunksize
  • From: Mark Kirkwood
• Re: Raid 10 chunksize
  • From: Mark Kirkwood
• Re: Strange behavior: pgbench and new Linux kernels
  • From: Greg Smith
• Re: How to get parallel restore in PG 8.4 to work?
  • From: Tom Lane
• How to get parallel restore in PG 8.4 to work?
  • From: henk de wit
• Re: Strange behavior: pgbench and new Linux kernels
  • From: Kevin Grittner
• Re: Very specialised query
  • From: Віталій Тимчишин
• Re: Very specialised query
  • From: Matthew Wakeling
• Re: I have a fusion IO drive available for testing
  • From: Chris Browne
• Re: I have a fusion IO drive available for testing
  • From: Craig James
• Re: I have a fusion IO drive available for testing
  • From: Dave Cramer
• Re: Very specialised query
  • From: Matthew Wakeling
• Re: Trying to track down weird query stalls
  • From: Scott Carey
• Re: Trying to track down weird query stalls
  • From: Alvaro Herrera
• Re: Trying to track down weird query stalls
  • From: dan
• Re: Trying to track down weird query stalls
  • From: Alvaro Herrera
• Re: Trying to track down weird query stalls
  • From: dan
• Re: Trying to track down weird query stalls
  • From: Alvaro Herrera
• Re: Trying to track down weird query stalls
  • From: dan
• Re: Trying to track down weird query stalls
  • From: Alvaro Herrera
• Re: Trying to track down weird query stalls
  • From: dan
• Re: Trying to track down weird query stalls
  • From: Robert Haas
• Re: Trying to track down weird query stalls
  • From: dan
• Re: Trying to track down weird query stalls
  • From: Scott Marlowe
• Re: Trying to track down weird query stalls
  • From: Scott Marlowe
• Re: Trying to track down weird query stalls
  • From: dan
• Re: Trying to track down weird query stalls
  • From: dan
• Re: Trying to track down weird query stalls
  • From: Robert Haas
• Re: Trying to track down weird query stalls
  • From: dan
• Re: Trying to track down weird query stalls
  • From: Robert Haas
• Re: Very specialised query
  • From: Віталій Тимчишин
• Trying to track down weird query stalls
  • From: dan
• Re: Very specialised query
  • From: Marc Mamin
• Re: Very specialised query
  • From: Віталій Тимчишин
• Re: Forcing seq_scan off for large table joined with tiny table yeilds improved performance
  • From: Scott Marlowe
• Re: Very specialised query
  • From: Matthew Wakeling
• Re: Very specialised query
  • From: Matthew Wakeling
• Re: Very specialised query
  • From: Matthew Wakeling
• Re: Very specialised query
  • From: Marc Mamin
• Re: Forcing seq_scan off for large table joined with tiny table yeilds improved performance
  • From: Mario Splivalo
• Re: Forcing seq_scan off for large table joined with tiny table yeilds improved performance
  • From: Tom Lane