Postgres Performance Date Index

• Thread Index

• Re: How to use indexes for GROUP BY
  • From: Scott Marlowe
• Re: How to use indexes for GROUP BY
  • From: Shaun Thomas
• How to use indexes for GROUP BY
  • From: Dimi Paun
• Re: Possible to improve query plan?
  • From: Kevin Grittner
• Re: Possible to improve query plan?
  • From: Tom Lane
• Re: Possible to improve query plan?
  • From: Tom Lane
• Re: Possible to improve query plan?
  • From: Kevin Grittner
• Re: Possible to improve query plan?
  • From: Robert Haas
• Re: "NOT IN" substantially slower in 9.0.2 than 8.3.13 - NOT EXISTS runs fast in both 8.3.13 and 9.0.2
  • From: Achilleas Mantzios
• Re: copy command and blobs
  • From: Robert Haas
• Re: copy command and blobs
  • From: Madhu Ramachandran
• Re: Fun little performance IMPROVEMENT...
  • From: grant
• Re: Fun little performance IMPROVEMENT...
  • From: grant
• Re: Fun little performance IMPROVEMENT...
  • From: Scott Carey
• Re: Fun little performance IMPROVEMENT...
  • From: grant
• Re: Fun little performance IMPROVEMENT...
  • From: grant
• Re: "NOT IN" substantially slower in 9.0.2 than 8.3.13 - NOT EXISTS runs fast in both 8.3.13 and 9.0.2
  • From: Tom Lane
• Re: Fun little performance IMPROVEMENT...
  • From: Greg Smith
• Re: "NOT IN" substantially slower in 9.0.2 than 8.3.13 - NOT EXISTS runs fast in both 8.3.13 and 9.0.2
  • From: Kevin Grittner
• Re: Fun little performance IMPROVEMENT...
  • From: Tom Lane
• Re: "NOT IN" substantially slower in 9.0.2 than 8.3.13 - NOT EXISTS runs fast in both 8.3.13 and 9.0.2
  • From: Tom Lane
• Re: Best way to get the latest revision from a table
  • From: Nikolas Everett
• Re: Fun little performance IMPROVEMENT...
  • From: Andy Colson
• Fun little performance IMPROVEMENT...
  • From: grant
• Re: "NOT IN" substantially slower in 9.0.2 than 8.3.13 - NOT EXISTS runs fast in both 8.3.13 and 9.0.2
  • From: Mladen Gogala
• Re: "NOT IN" substantially slower in 9.0.2 than 8.3.13 - NOT EXISTS runs fast in both 8.3.13 and 9.0.2
  • From: Robert Haas
• Re: the XID question
  • From: Robert Haas
• Re: "NOT IN" substantially slower in 9.0.2 than 8.3.13 - NOT EXISTS runs fast in both 8.3.13 and 9.0.2
  • From: Mladen Gogala
• Re: Best way to get the latest revision from a table
  • From: Robert Haas
• Re: "NOT IN" substantially slower in 9.0.2 than 8.3.13 - NOT EXISTS runs fast in both 8.3.13 and 9.0.2
  • From: Robert Haas
• Re: copy command and blobs
  • From: Tom Lane
• Re: copy command and blobs
  • From: Mladen Gogala
• copy command and blobs
  • From: Madhu Ramachandran
• Re: the XID question
  • From: Kevin Grittner
• Re: anti-join chosen even when slower than old plan
  • From: Cédric Villemain
• Re: anti-join chosen even when slower than old plan
  • From: Cédric Villemain
• Re: Migrating to Postgresql and new hardware
  • From: Scott Marlowe
• Re: Running PostgreSQL as fast as possible no matter the consequences
  • From: Robert Haas
• Re: the XID question
  • From: Charles.Hou
• Re: Migrating to Postgresql and new hardware
  • From: Andy Colson
• Re: anti-join chosen even when slower than old plan
  • From: Robert Haas
• Re: anti-join chosen even when slower than old plan
  • From: Cédric Villemain
• Re: "NOT IN" substantially slower in 9.0.2 than 8.3.13 - NOT EXISTS runs fast in both 8.3.13 and 9.0.2
  • From: Achilleas Mantzios
• Re: the XID question
  • From: Charles.Hou
• Re: Migrating to Postgresql and new hardware
  • From: Craig Ringer
• Re: the XID question
  • From: Greg Smith
• Re: anti-join chosen even when slower than old plan
  • From: Bruce Momjian
• Re: anti-join chosen even when slower than old plan
  • From: Bruce Momjian
• Re: anti-join chosen even when slower than old plan
  • From: Bruce Momjian
• Re: the XID question
  • From: Kevin Grittner
• Re: the XID question
  • From: Andres Freund
• Re: the XID question
  • From: Chris Browne
• Re: Running PostgreSQL as fast as possible no matter the consequences
  • From: Fabrízio de Royes Mello
• Re: "NOT IN" substantially slower in 9.0.2 than 8.3.13 - NOT EXISTS runs fast in both 8.3.13 and 9.0.2
  • From: Tom Lane
• Re: Running PostgreSQL as fast as possible no matter the consequences
  • From: Bruce Momjian
• Re: the XID question
  • From: Kevin Grittner
• Re: the XID question
  • From: Filip Rembiałkowski
• Re: the XID question
  • From: Charles.Hou
• the XID question
  • From: Charles.Hou
• Re: Migrating to Postgresql and new hardware
  • From: Lars
• Re: Migrating to Postgresql and new hardware
  • From: Lars
• Re: Migrating to Postgresql and new hardware
  • From: Lars
• Re: "NOT IN" substantially slower in 9.0.2 than 8.3.13 - NOT EXISTS runs fast in both 8.3.13 and 9.0.2
  • From: Achilleas Mantzios
• Re: Migrating to Postgresql and new hardware
  • From: Scott Marlowe
• Re: Migrating to Postgresql and new hardware
  • From: Craig Ringer
• Re: Migrating to Postgresql and new hardware
  • From: mark
• Re: Migrating to Postgresql and new hardware
  • From: Mark Felder
• Re: Migrating to Postgresql and new hardware
  • From: Strange, John W
• Re: hashed subplan 5000x slower than two sequential operations
  • From: Віталій Тимчишин
• Re: Migrating to Postgresql and new hardware
  • From: Andy Colson
• Re: Migrating to Postgresql and new hardware
  • From: Andy Colson
• Re: hashed subplan 5000x slower than two sequential operations
  • From: masterchief
• Migrating to Postgresql and new hardware
  • From: Lars
• Re: "NOT IN" substantially slower in 9.0.2 than 8.3.13 - NOT EXISTS runs fast in both 8.3.13 and 9.0.2
  • From: Mladen Gogala
• Re: Bad plan when join on function
  • From: Shaun Thomas
• Re: The good, old times
  • From: Dave Page
• Re: The good, old times
  • From: Devrim GÜNDÜZ
• Re: "NOT IN" substantially slower in 9.0.2 than 8.3.13 - NOT EXISTS runs fast in both 8.3.13 and 9.0.2
  • From: Achilleas Mantzios
• Re: Problem with query
  • From: Fernando Hevia
• Re: Possible to improve query plan?
  • From: Mladen Gogala
• Re: Bad plan when join on function
  • From: Pavel Stehule
• Re: Bad plan when join on function
  • From: Tom Lane
• Re: Bad plan when join on function
  • From: Pavel Stehule
• Re: Possible to improve query plan?
  • From: Jeremy Palmer
• Re: Possible to improve query plan?
  • From: Jeremy Palmer
• Re: Bad plan when join on function
  • From: Kevin Grittner
• Re: Possible to improve query plan?
  • From: Tom Lane
• Re: Bad plan when join on function
  • From: Pavel Stehule
• Bad plan when join on function
  • From: Zotov
• Re: Possible to improve query plan?
  • From: Kevin Grittner
• Re: "NOT IN" substantially slower in 9.0.2 than 8.3.13 - NOT EXISTS runs fast in both 8.3.13 and 9.0.2
  • From: Mladen Gogala
• Re: "NOT IN" substantially slower in 9.0.2 than 8.3.13 - NOT EXISTS runs fast in both 8.3.13 and 9.0.2
  • From: Ing. Marcos Ortiz Valmaseda
• "NOT IN" substantially slower in 9.0.2 than 8.3.13 - NOT EXISTS runs fast in both 8.3.13 and 9.0.2
  • From: Achilleas Mantzios
• Re: Possible to improve query plan?
  • From: Ing. Marcos Ortiz Valmaseda
• Re: Possible to improve query plan?
  • From: Jayadevan M
• Re: Possible to improve query plan?
  • From: Jeremy Palmer
• Re: Possible to improve query plan?
  • From: Andy Colson
• Possible to improve query plan?
  • From: Jeremy Palmer
• Re: Possible to improve query plan?
  • From: Andy Colson
• Possible to improve query plan?
  • From: Jeremy Palmer
• Re: The good, old times
  • From: Craig Ringer
• Re: Best way to get the latest revision from a table
  • From: Shaun Thomas
• Re: Best way to get the latest revision from a table
  • From: Shaun Thomas
• Re: queries with lots of UNIONed relations
  • From: Jon Nelson
• Problem with query
  • From: Barbara Woolums
• Re: The good, old times
  • From: Craig Ringer
• Re: Best way to get the latest revision from a table
  • From: Nikolas Everett
• Re: Best way to get the latest revision from a table
  • From: Kevin Grittner
• Re: Best way to get the latest revision from a table
  • From: Tom Lane
• Re: Best way to get the latest revision from a table
  • From: Kevin Grittner
• Re: Best way to get the latest revision from a table
  • From: Shaun Thomas
• Re: Best way to get the latest revision from a table
  • From: Kevin Grittner
• Re: "COPY TO stdout" statements occurrence in log files
  • From: Marti Raudsepp
• Re: Best way to get the latest revision from a table
  • From: Nikolas Everett
• Re: Best way to get the latest revision from a table
  • From: Kevin Grittner
• Re: "COPY TO stdout" statements occurrence in log files
  • From: Chris Browne
• Best way to get the latest revision from a table
  • From: Nikolas Everett
• Re: "COPY TO stdout" statements occurrence in log files
  • From: Maciek Sakrejda
• Re: queries with lots of UNIONed relations
  • From: Jon Nelson
• "COPY TO stdout" statements occurrence in log files
  • From: Fernando Mertins
• Re: Problems with FTS
  • From: Robert Haas
• Re: "SELECT .. WHERE NOT IN" query running for hours
  • From: Robert Haas
• Re: plan question - query with order by and limit not choosing index depends on size of limit, table
  • From: Robert Haas
• Re: The good, old times
  • From: Mladen Gogala
• Re: plan question - query with order by and limit not choosing index depends on size of limit, table
  • From: Mike Broers
• Re: queries with lots of UNIONed relations
  • From: Vitalii Tymchyshyn
• Re: The good, old times
  • From: Craig Ringer
• Re: queries with lots of UNIONed relations
  • From: Mladen Gogala
• Re: queries with lots of UNIONed relations
  • From: Tom Lane
• Re: queries with lots of UNIONed relations
  • From: Jon Nelson
• Re: queries with lots of UNIONed relations
  • From: Tom Lane
• Re: queries with lots of UNIONed relations
  • From: Tom Lane
• Re: queries with lots of UNIONed relations
  • From: Jon Nelson
• Re: queries with lots of UNIONed relations
  • From: Andy Colson
• Re: queries with lots of UNIONed relations
  • From: Robert Haas
• Re: queries with lots of UNIONed relations
  • From: Andy Colson
• Re: queries with lots of UNIONed relations
  • From: Robert Haas
• Re: queries with lots of UNIONed relations
  • From: Robert Haas
• Re: queries with lots of UNIONed relations
  • From: Tom Lane
• Re: queries with lots of UNIONed relations
  • From: Robert Haas
• Re: adding foreign key constraint locks up table
  • From: kakarukeys
• queries with lots of UNIONed relations
  • From: Jon Nelson
• Re: queries with lots of UNIONed relations
  • From: Jon Nelson
• Re: queries with lots of UNIONed relations
  • From: Tom Lane
• Re: queries with lots of UNIONed relations
  • From: Jon Nelson
• Re: queries with lots of UNIONed relations
  • From: Tom Lane
• queries with lots of UNIONed relations
  • From: Jon Nelson
• Re: Slow query + why bitmap index scan??
  • From: Cédric Villemain
• Re: Performance test of Oracle and PostgreSQL using same binary
  • From: Jeff Janes
• Re: Slow query + why bitmap index scan??
  • From: Kevin Grittner
• Re: Slow query + why bitmap index scan??
  • From: Laszlo Nagy
• Re: Slow query + why bitmap index scan??
  • From: Kevin Grittner
• Re: Slow query + why bitmap index scan??
  • From: Kenneth Marshall
• Re: Slow query + why bitmap index scan??
  • From: Laszlo Nagy
• Re: The good, old times
  • From: Guillaume Cottenceau
• The good, old times
  • From: Mladen Gogala
• Re: Slow query + why bitmap index scan??
  • From: Florian Weimer
• Slow query + why bitmap index scan??
  • From: Laszlo Nagy
• Re: How to turn autovacuum prevent wrap around run faster?
  • From: marc.hsiao
• Performance test of Oracle and PostgreSQL using same binary
  • From: Divakar Singh
• Re: Performance of PostgreSQL over NFS
  • From: Jignesh Shah
• Re: pgbench to the MAXINT
  • From: Euler Taveira de Oliveira
• Re: Problems with FTS
  • From: Rauan Maemirov
• Re: "SELECT .. WHERE NOT IN" query running for hours
  • From: Scott Carey
• Re: "SELECT .. WHERE NOT IN" query running for hours
  • From: Kevin Grittner
• Re: "SELECT .. WHERE NOT IN" query running for hours
  • From: Scott Carey
• Re: "SELECT .. WHERE NOT IN" query running for hours
  • From: Mladen Gogala
• Re: plan question - query with order by and limit not choosing index depends on size of limit, table
  • From: Mike Broers
• Re: pgbench to the MAXINT
  • From: Greg Smith
• Re: pgbench to the MAXINT
  • From: Euler Taveira de Oliveira
• Re: MySQL HandlerSocket - Is this possible in PG?
  • From: Dimitri Fontaine
• Re: adding foreign key constraint locks up table
  • From: Robert Haas
• pgbench to the MAXINT
  • From: Greg Smith
• Re: Wrong docs on wal_buffers?
  • From: Greg Smith
• Re: Wrong docs on wal_buffers?
  • From: Samuel Gendler
• Re: Wrong docs on wal_buffers?
  • From: Tom Lane
• Re: Wrong docs on wal_buffers?
  • From: Samuel Gendler
• Re: plan question - query with order by and limit not choosing index depends on size of limit, table
  • From: pasman pasmański
• Re: Wrong docs on checkpoint_segments?
  • From: Andres Freund
• Re: Wrong docs on checkpoint_segments?
  • From: Florian Weimer
• Re: Wrong docs on checkpoint_segments?
  • From: Andres Freund
• Wrong docs on checkpoint_segments?
  • From: Florian Weimer
• Re: "SELECT .. WHERE NOT IN" query running for hours
  • From: Γιωργος Βαλκανας
• Re: How to turn autovacuum prevent wrap around run faster?
  • From: marc47marc47
• Re: Major performance problem after upgrade from 8.3 to 8.4
  • From: Marc Antonio
• Re: adding foreign key constraint locks up table
  • From: kakarukeys
• Re: How to turn autovacuum prevent wrap around run faster?
  • From: marc.hsiao
• Re: Wrong docs on wal_buffers?
  • From: Greg Smith
• Re: "SELECT .. WHERE NOT IN" query running for hours
  • From: Mladen Gogala
• "SELECT .. WHERE NOT IN" query running for hours
  • From: Γιωργος Βαλκανας
• Re: Wrong docs on wal_buffers?
  • From: Jeff Janes
• Re: Wrong docs on wal_buffers?
  • From: Scott Carey
• Re: postgres performance tunning
  • From: Scott Marlowe
• Re: postgres performance tunning
  • From: Scott Marlowe
• Re: plan question - query with order by and limit not choosing index depends on size of limit, table
  • From: Mike Broers
• Re: postgres performance tunning
  • From: Robert Haas
• Re: Wrong docs on wal_buffers?
  • From: Josh Berkus
• Re: plan question - query with order by and limit not choosing index depends on size of limit, table
  • From: Kevin Grittner
• Re: Wrong docs on wal_buffers?
  • From: Pierre C
• plan question - query with order by and limit not choosing index depends on size of limit, table
  • From: Mike Broers
• Re: Wrong docs on wal_buffers?
  • From: Jeff Janes
• Wrong docs on wal_buffers?
  • From: Josh Berkus
• Re: Question: BlockSize > 8192 with FusionIO
  • From: Scott Carey
• Re: Same stament sometime fast, something slow
  • From: Greg Smith
• Re: Same stament sometime fast, something slow
  • From: Craig Ringer
• Re: Question: BlockSize > 8192 with FusionIO
  • From: Strange, John W
• Re: Question: BlockSize > 8192 with FusionIO
  • From: Strange, John W
• Re: Question: BlockSize > 8192 with FusionIO
  • From: Ben Chobot
• Re: Same stament sometime fast, something slow
  • From: Kevin Grittner
• Same stament sometime fast, something slow
  • From: Fernando Mertins
• Re: Question: BlockSize > 8192 with FusionIO
  • From: Merlin Moncure
• Re: adding foreign key constraint locks up table
  • From: Tom Lane
• Re: PostgreSQL
  • From: Greg Smith
• Re: concurrent IO in postgres?
  • From: Greg Smith
• Re: adding foreign key constraint locks up table
  • From: Florian Weimer
• Re: Performance of PostgreSQL over NFS
  • From: Greg Smith
• Re: Question: BlockSize > 8192 with FusionIO
  • From: Greg Smith
• Question: BlockSize > 8192 with FusionIO
  • From: Strange, John W
• Re: CPU bound
  • From: Mladen Gogala
• Re: How to turn autovacuum prevent wrap around run faster?
  • From: marc.hsiao
• Re: CPU bound
  • From: Jim Nasby
• Re: encourging bitmap AND
  • From: Jim Nasby
• Re: PostgreSQL
  • From: Lew
• Re: long wait times in ProcessCatchupEvent()
  • From: Julian v. Bock
• Re: long wait times in ProcessCatchupEvent()
  • From: Kevin Grittner
• PostgreSQL
  • From: nextage Tech
• Re: long wait times in ProcessCatchupEvent()
  • From: Mladen Gogala
• Re: long wait times in ProcessCatchupEvent()
  • From: Craig James
• Re: long wait times in ProcessCatchupEvent()
  • From: Tom Lane
• Re: long wait times in ProcessCatchupEvent()
  • From: Craig James
• Re: long wait times in ProcessCatchupEvent()
  • From: Tom Lane
• long wait times in ProcessCatchupEvent()
  • From: Julian v. Bock
• Re: Regression: 8.3 2 seconds -> 8.4 100+ seconds
  • From: Greg Smith
• Re: adding foreign key constraint locks up table
  • From: Tom Lane
• Re: adding foreign key constraint locks up table
  • From: Kevin Grittner
• Re: adding foreign key constraint locks up table
  • From: Gurjeet Singh
• Re: adding foreign key constraint locks up table
  • From: Gurjeet Singh
• Re: adding foreign key constraint locks up table
  • From: Florian Weimer
• Re: adding foreign key constraint locks up table
  • From: kakarukeys
• Re: adding foreign key constraint locks up table
  • From: Lew
• Re: adding foreign key constraint locks up table
  • From: Kevin Grittner
• Re: adding foreign key constraint locks up table
  • From: Gurjeet Singh
• adding foreign key constraint locks up table
  • From: kakarukeys
• Re: How to turn autovacuum prevent wrap around run faster?
  • From: Scott Marlowe
• How to turn autovacuum prevent wrap around run faster?
  • From: marc.hsiao
• Re: encourging bitmap AND
  • From: Tom Lane
• Re: concurrent IO in postgres?
  • From: Jeff Janes
• Index on function that returns type with sub fields
  • From: Desmond Coertzen
• Re: encourging bitmap AND
  • From: Marti Raudsepp
• Re: concurrent IO in postgres?
  • From: Mladen Gogala
• Re: concurrent IO in postgres?
  • From: Jeff Janes
• Re: concurrent IO in postgres?
  • From: Pierre C
• Re: concurrent IO in postgres?
  • From: Josh Berkus
• Re: concurrent IO in postgres?
  • From: John Cagle
• Re: concurrent IO in postgres?
  • From: Ben Chobot
• Re: encourging bitmap AND
  • From: Ben
• Re: encourging bitmap AND
  • From: Tom Lane
• encourging bitmap AND
  • From: Ben
• Re: concurrent IO in postgres?
  • From: Andy
• Re: concurrent IO in postgres?
  • From: Przemek Wozniak
• Re: concurrent IO in postgres?
  • From: Kevin Grittner
• Re: concurrent IO in postgres?
  • From: John W Strange
• Re: concurrent IO in postgres?
  • From: Scott Marlowe
• concurrent IO in postgres?
  • From: Przemek Wozniak
• Re: Create index on subfield returned by function that returns base type with sub fields
  • From: Andres Freund
• Create index on subfield returned by function that returns base type with sub fields
  • From: Desmond Coertzen
• Re: PostgreSQL 9.0 x64 bit pgbench TPC very low question?
  • From: Jeff Janes
• Re: PostgreSQL 9.0 x64 bit pgbench TPC very low question?
  • From: tuanhoanganh
• Re: PostgreSQL 9.0 x64 bit pgbench TPC very low question?
  • From: Kenneth Marshall
• Re: PostgreSQL 9.0 x64 bit pgbench TPC very low question?
  • From: Kevin Grittner
• Re: PostgreSQL 9.0 x64 bit pgbench TPC very low question?
  • From: tuanhoanganh
• Re: BBU Cache vs. spindles
  • From: Bruce Momjian
• Re: MySQL HandlerSocket - Is this possible in PG?
  • From: Michael Ben-Nes
• Re: MySQL HandlerSocket - Is this possible in PG?
  • From: Pierre C
• Re: Query uses incorrect index
  • From: pasman pasmański
• Re: Query uses incorrect index
  • From: Tom Lane
• Re: Query uses incorrect index
  • From: Kevin Grittner
• Re: PostgreSQL 9.0 x64 bit pgbench TPC very low question?
  • From: Gurjeet Singh
• Re: PostgreSQL 9.0 x64 bit pgbench TPC very low question?
  • From: tuanhoanganh
• Re: MySQL HandlerSocket - Is this possible in PG?
  • From: Marti Raudsepp
• Re: Query uses incorrect index
  • From: Guillaume Cottenceau
• Re: Query uses incorrect index
  • From: pasman pasmański
• Re: MySQL HandlerSocket - Is this possible in PG?
  • From: Scott Marlowe
• Re: MySQL HandlerSocket - Is this possible in PG?
  • From: Pierre C
• Re: MySQL HandlerSocket - Is this possible in PG?
  • From: Michael Ben-Nes
• Re: Performance of PostgreSQL over NFS
  • From: Mladen Gogala
• Re: MySQL HandlerSocket - Is this possible in PG?
  • From: Merlin Moncure
• Re: Performance of PostgreSQL over NFS
  • From: Rich
• Performance of PostgreSQL over NFS
  • From: Mladen Gogala
• Re: MySQL HandlerSocket - Is this possible in PG?
  • From: Pavel Stehule
• Re: Query uses incorrect index
  • From: Kevin Grittner
• Query uses incorrect index
  • From: pasman pasmański
• Re: CPU bound
  • From: Mladen Gogala
• Re: MySQL HandlerSocket - Is this possible in PG?
  • From: Pavel Stehule
• MySQL HandlerSocket - Is this possible in PG?
  • From: Michael Ben-Nes
• Re: PostgreSQL 9.0 x64 bit pgbench TPC very low question?
  • From: Magnus Hagander
• Re: PostgreSQL 9.0 x64 bit pgbench TPC very low question?
  • From: Scott Marlowe
• Re: PostgreSQL 9.0 x64 bit pgbench TPC very low question?
  • From: tuanhoanganh
• Re: UNION and bad performance
  • From: Robert Haas
• Re: postgres performance tunning
  • From: Scott Marlowe
• Re: CPU bound
  • From: Jeremy Harris
• Re: postgres performance tunning
  • From: Greg Smith
• Re: postgres performance tunning
  • From: Scott Marlowe
• Re: postgres performance tunning
  • From: Fernando Hevia
• Re: CPU bound
  • From: Kenneth Marshall
• Re: CPU bound
  • From: James Cloos
• Re: PostgreSQL 9.0 x64 bit pgbench TPC very low question?
  • From: Scott Marlowe
• Re: PostgreSQL 9.0 x64 bit pgbench TPC very low question?
  • From: Scott Marlowe
• Re: PostgreSQL 9.0 x64 bit pgbench TPC very low question?
  • From: tuanhoanganh
• Re: CPU bound
  • From: Mladen Gogala
• Re: CPU bound
  • From: James Cloos
• Re: Strange optimization - xmin,xmax compression :)
  • From: Jim Nasby
• Re: postgres performance tunning
  • From: selvi88
• Re: Compared MS SQL 2000 to Postgresql 9.0 on Windows
  • From: Justin Pitts
• Re: postgres performance tunning
  • From: selvi88
• Re: Auto-clustering?
  • From: Royce Ausburn
• Re: Auto-clustering?
  • From: Royce Ausburn
• Re: PostgreSQL 9.0 x64 bit pgbench TPC very low question?
  • From: Ivan Voras
• Re: PostgreSQL 9.0 x64 bit pgbench TPC very low question?
  • From: Jeff Janes
• Re: PostgreSQL 9.0 x64 bit pgbench TPC very low question?
  • From: tuanhoanganh
• Re: PostgreSQL 9.0 x64 bit pgbench TPC very low question?
  • From: tuanhoanganh
• Re: PostgreSQL 9.0 x64 bit pgbench TPC very low question?
  • From: tuanhoanganh
• Re: PostgreSQL 9.0 x64 bit pgbench TPC very low question?
  • From: Jeff Janes
• Re: PostgreSQL 9.0 x64 bit pgbench TPC very low question?
  • From: Kevin Grittner
• PostgreSQL 9.0 x64 bit pgbench TPC very low question?
  • From: tuanhoanganh
• Re: Problems with FTS
  • From: Kevin Grittner
• Re: Compared MS SQL 2000 to Postgresql 9.0 on Windows
  • From: Kevin Grittner
• Re: Compared MS SQL 2000 to Postgresql 9.0 on Windows
  • From: Pierre C
• Re: Compared MS SQL 2000 to Postgresql 9.0 on Windows
  • From: Scott Marlowe
• Re: Compared MS SQL 2000 to Postgresql 9.0 on Windows
  • From: Gael Le Mignot
• Re: Index Bloat - how to tell?
  • From: Mladen Gogala
• Re: Strange optimization - xmin,xmax compression :)
  • From: Robert Haas
• Re: Index Bloat - how to tell?
  • From: Robert Haas
• Re: Compared MS SQL 2000 to Postgresql 9.0 on Windows
  • From: Scott Marlowe
• Re: Compared MS SQL 2000 to Postgresql 9.0 on Windows
  • From: Robert Haas
• Re: postgres performance tunning
  • From: Merlin Moncure
• Re: Compared MS SQL 2000 to Postgresql 9.0 on Windows
  • From: Tom Polak
• Re: Compared MS SQL 2000 to Postgresql 9.0 on Windows
  • From: Andy Colson
• Re: Compared MS SQL 2000 to Postgresql 9.0 on Windows
  • From: Andy Colson
• Re: Compared MS SQL 2000 to Postgresql 9.0 on Windows
  • From: Robert Haas
• Re: Compared MS SQL 2000 to Postgresql 9.0 on Windows
  • From: Rob Wultsch
• Re: Compared MS SQL 2000 to Postgresql 9.0 on Windows
  • From: Richard Broersma
• Re: Compared MS SQL 2000 to Postgresql 9.0 on Windows
  • From: Craig James
• Re: Compared MS SQL 2000 to Postgresql 9.0 on Windows
  • From: Tom Polak
• Re: Auto-clustering?
  • From: phb07
• Re: postgres performance tunning
  • From: Marti Raudsepp
• Re: Help with bulk read performance
  • From: Nick Matheson
• Re: postgres performance tunning
  • From: Greg Smith
• Re: Auto-clustering?
  • From: Pierre C
• Re: Auto-clustering?
  • From: Filip Rembiałkowski
• Re: postgres performance tunning
  • From: Pierre C
• Re: Auto-clustering?
  • From: Marti Raudsepp
• Re: Auto-clustering?
  • From: Filip Rembiałkowski
• Auto-clustering?
  • From: Royce Ausburn
• Re: How to get FK to use new index without restarting the database
  • From: Eric Comeau
• postgres performance tunning
  • From: selvi88
• Re: How to get FK to use new index without restarting the database
  • From: Eric Comeau
• Re: Index Bloat - how to tell?
  • From: Mladen Gogala
• Re: How to get FK to use new index without restarting the database
  • From: Tom Lane
• Re: Help with bulk read performance
  • From: Pierre C
• Re: performance libpq vs JDBC
  • From: Merlin Moncure
• Re: Help with bulk read performance
  • From: Krzysztof Nienartowicz
• Re: How to get FK to use new index without restarting the database
  • From: Eric Comeau
• Re: How to get FK to use new index without restarting the database
  • From: Richard Huxton
• Re: performance libpq vs JDBC
  • From: Richard Huxton
• Re: How to get FK to use new index without restarting the database
  • From: Jayadevan M
• Re: performance libpq vs JDBC
  • From: Werner Scholtes
• How to get FK to use new index without restarting the database
  • From: Eric Comeau
• Re: performance libpq vs JDBC
  • From: Richard Huxton
• Re: performance libpq vs JDBC
  • From: Divakar Singh
• Re: performance libpq vs JDBC
  • From: Werner Scholtes
• Re: performance libpq vs JDBC
  • From: Divakar Singh
• Re: performance libpq vs JDBC
  • From: Werner Scholtes
• Re: performance libpq vs JDBC
  • From: Divakar Singh
• Re: Help with bulk read performance
  • From: Dan Schaffer
• performance libpq vs JDBC
  • From: Werner Scholtes
• Problems with FTS
  • From: Rauan Maemirov
• Re: only one index is using, why?
  • From: Marti Raudsepp
• only one index is using, why?
  • From: AI Rumman
• Re: Index Bloat - how to tell?
  • From: Mark Kirkwood
• Re: Index Bloat - how to tell?
  • From: Dave Crooke
• Re: Help with bulk read performance
  • From: Nick Matheson
• Re: Help with bulk read performance
  • From: Jim Nasby
• Re: Index Bloat - how to tell?
  • From: Mladen Gogala
• Re: Help with bulk read performance
  • From: Andy Colson
• Re: Help with bulk read performance
  • From: Jim Nasby
• Re: Help with bulk read performance
  • From: Andy Colson
• Re: Index Bloat - how to tell?
  • From: Plugge, Joe R.
• Index Bloat - how to tell?
  • From: John W Strange
• Re: CPU bound
  • From: Royce Ausburn
• Re: Help with bulk read performance
  • From: Jim Nasby
• Re: Tunning Postgres
  • From: Grzegorz Jaśkiewicz
• Re: Hardware recommendations
  • From: mark
• Re: Tunning Postgres
  • From: Robert Haas
• Re: Hardware recommendations
  • From: Benjamin Krajmalnik
• Re: CPU bound
  • From: Josh Berkus
• Re: CPU bound
  • From: Craig Ringer
• CPU bound
  • From: Royce Ausburn
• Re: SELECT INTO large FKyed table is slow
  • From: Robert Haas
• Re: UNION and bad performance
  • From: pasman pasmański
• Re: UNION and bad performance
  • From: Andreas Kretschmer
• Re: UNION and bad performance
  • From: Marc Mamin
• UNION and bad performance
  • From: Olivier Pala
• Tunning Postgres
  • From: salima
• Re: Hardware recommendations
  • From: Greg Smith
• Re: Hardware recommendations
  • From: Greg Smith
• Re: Hardware recommendations
  • From: Andy
• Re: Hardware recommendations
  • From: Scott Marlowe
• Re: Hardware recommendations
  • From: Arjen van der Meijden
• Re: Hardware recommendations
  • From: Arjen van der Meijden
• Re: Hardware recommendations
  • From: Andy
• Re: Hardware recommendations
  • From: alan bryan
• Re: libpq vs ODBC
  • From: Pierre C
• Re: Hardware recommendations
  • From: John W Strange
• Re: Hardware recommendations
  • From: Marti Raudsepp
• Re: libpq vs ODBC
  • From: Pavel Stehule
• Re: libpq vs ODBC
  • From: Divakar Singh
• Re: libpq vs ODBC
  • From: Alex Goncharov
• Re: Slow BLOBs restoring
  • From: Tom Lane
• Re: Hardware recommendations
  • From: mark
• Re: libpq vs ODBC
  • From: Divakar Singh
• Re: libpq vs ODBC
  • From: Alex Goncharov
• libpq vs ODBC
  • From: Divakar Singh
• Re: Slow BLOBs restoring
  • From: Vlad Arkhipov
• Re: Slow BLOBs restoring
  • From: Vlad Arkhipov
• Re: Hardware recommendations
  • From: Scott Marlowe
• Re: Performance under contention
  • From: Robert Haas
• Re: Hardware recommendations
  • From: alaricd
• Re: Hardware recommendations
  • From: alaricd
• Re: Hardware recommendations
  • From: alaricd
• Re: Hardware recommendations
  • From: alaricd
• Re: Hardware recommendations
  • From: Andy
• Re: Hardware recommendations
  • From: alaricd
• Re: Hardware recommendations
  • From: Marti Raudsepp
• Re: Hardware recommendations
  • From: John W Strange
• Re: Hardware recommendations
  • From: Benjamin Krajmalnik
• Re: Hardware recommendations
  • From: alaricd
• Re: Compared MS SQL 2000 to Postgresql 9.0 on Windows
  • From: Pierre C
• Re: Hardware recommendations
  • From: Andy
• Hardware recommendations
  • From: Benjamin Krajmalnik
• Re: Performance under contention
  • From: Tom Lane
• Re: Performance under contention
  • From: Robert Haas
• Re: hashed subplan 5000x slower than two sequential operations
  • From: Bryce Nesbitt
• Re: hashed subplan 5000x slower than two sequential operations
  • From: Bryce Nesbitt
• Re: hashed subplan 5000x slower than two sequential operations
  • From: Pavel Stehule
• Re: hashed subplan 5000x slower than two sequential operations
  • From: Marc Mamin
• Re: hashed subplan 5000x slower than two sequential operations
  • From: Tom Lane
• Re: hashed subplan 5000x slower than two sequential operations
  • From: Marc Mamin
• Re: hashed subplan 5000x slower than two sequential operations
  • From: Bryce Nesbitt
• Re: hashed subplan 5000x slower than two sequential operations
  • From: Shrirang Chitnis
• Re: Group commit and commit delay/siblings
  • From: Simon Riggs
• hashed subplan 5000x slower than two sequential operations
  • From: Bryce Nesbitt
• Re: Slow BLOBs restoring
  • From: Tom Lane
• Re: Performance under contention
  • From: Tom Lane
• Re: Slow BLOBs restoring
  • From: Vlad Arkhipov
• Re: Performance under contention
  • From: Robert Haas
• Re: Performance under contention
  • From: Robert Haas
• Re: Performance under contention
  • From: Ivan Voras
• Re: Compared MS SQL 2000 to Postgresql 9.0 on Windows
  • From: Kevin Grittner
• Re: Update problem on large table
  • From: Josh Kupershmidt
• Re: Compared MS SQL 2000 to Postgresql 9.0 on Windows
  • From: Gary Doades
• Re: Compared MS SQL 2000 to Postgresql 9.0 on Windows
  • From: Craig James
• Re: Performance under contention
  • From: Віталій Тимчишин
• Re: Compared MS SQL 2000 to Postgresql 9.0 on Windows
  • From: Tom Polak
• Re: Compared MS SQL 2000 to Postgresql 9.0 on Windows
  • From: Andy Colson
• Re: Compared MS SQL 2000 to Postgresql 9.0 on Windows
  • From: Mladen Gogala
• Re: Compared MS SQL 2000 to Postgresql 9.0 on Windows
  • From: Gary Doades
• Re: Compared MS SQL 2000 to Postgresql 9.0 on Windows
  • From: Kenneth Marshall
• Re: Compared MS SQL 2000 to Postgresql 9.0 on Windows
  • From: Richard Broersma
• Re: Compared MS SQL 2000 to Postgresql 9.0 on Windows
  • From: Andy Colson
• Re: Compared MS SQL 2000 to Postgresql 9.0 on Windows
  • From: Craig James
• Re: Performance under contention
  • From: Ivan Voras
• Re: Compared MS SQL 2000 to Postgresql 9.0 on Windows
  • From: Andres Freund
• Re: Compared MS SQL 2000 to Postgresql 9.0 on Windows
  • From: Andy Colson
• Re: Compared MS SQL 2000 to Postgresql 9.0 on Windows
  • From: Kevin Grittner
• Re: Performance under contention
  • From: Robert Haas
• Re: Performance under contention
  • From: Robert Haas
• Re: Performance under contention
  • From: Ivan Voras
• Compared MS SQL 2000 to Postgresql 9.0 on Windows
  • From: Tom Polak
• Re: Performance under contention
  • From: Dave Crooke
• Re: Performance under contention
  • From: Tom Lane
• Re: Performance under contention
  • From: Robert Haas
• Slow BLOBs restoring
  • From: Vlad Arkhipov
• Re: Group commit and commit delay/siblings
  • From: Greg Smith
• Re: Group commit and commit delay/siblings
  • From: Jignesh Shah
• Re: Performance under contention
  • From: Jignesh Shah
• Re: Performance under contention
  • From: Jignesh Shah
• Re: Query-plan for partitioned UPDATE/DELETE slow and swaps vmem compared to SELECT
  • From: John Papandriopoulos
• Re: Update problem on large table
  • From: felix
• Re: Update problem on large table
  • From: Kenneth Marshall
• Re: Update problem on large table
  • From: Josh Kupershmidt
• Re: Update problem on large table
  • From: Jon Nelson
• Re: Update problem on large table
  • From: bricklen
• Re: Performance under contention
  • From: Robert Haas
• Re: Query-plan for partitioned UPDATE/DELETE slow and swaps vmem compared to SELECT
  • From: Tom Lane
• Re: Group commit and commit delay/siblings
  • From: Tom Lane
• Re: Performance under contention
  • From: Robert Haas
• Strange optimization - xmin,xmax compression :)
  • From: pasman pasmański
• Re: Group commit and commit delay/siblings
  • From: Jignesh Shah
• Re: Query-plan for partitioned UPDATE/DELETE slow and swaps vmem compared to SELECT
  • From: John Papandriopoulos
• Re: Group commit and commit delay/siblings
  • From: Greg Smith
• Re: Group commit and commit delay/siblings
  • From: Jignesh Shah
• Re: Group commit and commit delay/siblings
  • From: Rob Wultsch
• Re: Group commit and commit delay/siblings
  • From: Jignesh Shah
• Group commit and commit delay/siblings
  • From: Rob Wultsch
• Re: Query-plan for partitioned UPDATE/DELETE slow and swaps vmem compared to SELECT
  • From: Tom Lane
• Re: Query-plan for partitioned UPDATE/DELETE slow and swaps vmem compared to SELECT
  • From: Tom Lane
• Re: Query-plan for partitioned UPDATE/DELETE slow and swaps vmem compared to SELECT
  • From: John Papandriopoulos
• Re: Query-plan for partitioned UPDATE/DELETE slow and swaps vmem compared to SELECT
  • From: John Papandriopoulos
• Re: Query-plan for partitioned UPDATE/DELETE slow and swaps vmem compared to SELECT
  • From: John Papandriopoulos
• Re: Query-plan for partitioned UPDATE/DELETE slow and swaps vmem compared to SELECT
  • From: Jochen Erwied
• Re: Query-plan for partitioned UPDATE/DELETE slow and swaps vmem compared to SELECT
  • From: Mladen Gogala
• Re: Query-plan for partitioned UPDATE/DELETE slow and swaps vmem compared to SELECT
  • From: Tom Lane
• Re: Query-plan for partitioned UPDATE/DELETE slow and swaps vmem compared to SELECT
  • From: Mladen Gogala
• Re: Query-plan for partitioned UPDATE/DELETE slow and swaps vmem compared to SELECT
  • From: John Papandriopoulos
• Re: Update problem on large table
  • From: felix
• Re: problem with from_collapse_limit and joined views
  • From: Markus Schulz
• Re: problem with from_collapse_limit and joined views
  • From: Markus Schulz
• Re: problem with from_collapse_limit and joined views
  • From: Tom Lane
• Re: Query-plan for partitioned UPDATE/DELETE slow and swaps vmem compared to SELECT
  • From: Tom Lane
• Re: Slow query to get last created row using CURRVAL
  • From: Віталій Тимчишин
• Re: problem with from_collapse_limit and joined views
  • From: Kevin Grittner
• Re: Slow query to get last created row using CURRVAL
  • From: Mathieu De Zutter
• Re: Slow query to get last created row using CURRVAL
  • From: Marti Raudsepp
• Slow query to get last created row using CURRVAL
  • From: Mathieu De Zutter
• Re: problem with from_collapse_limit and joined views
  • From: Markus Schulz
• Re: Query-plan for partitioned UPDATE/DELETE slow and swaps vmem compared to SELECT
  • From: John Papandriopoulos
• Re: Query-plan for partitioned UPDATE/DELETE slow and swaps vmem compared to SELECT
  • From: Tom Lane
• Query-plan for partitioned UPDATE/DELETE slow and swaps vmem compared to SELECT
  • From: John Papandriopoulos
• Re: problem with from_collapse_limit and joined views
  • From: Kevin Grittner
• Re: CPUs for new databases
  • From: Scott Carey
• Re: executor stats / page reclaims
  • From: Robert Haas
• PostBIX to monitor postgresql performaces
  • From: Andrea Dalle Vacche
• Re: Multicore Postgres 9.0.1 issue - single transaction problem.
  • From: Scott Marlowe
• Multicore Postgres 9.0.1 issue - single transaction problem.
  • From: Piotr Czekalski
• Re: SELECT INTO large FKyed table is slow
  • From: Kevin Grittner
• Re: SELECT INTO large FKyed table is slow
  • From: Mario Splivalo
• Re: SELECT INTO large FKyed table is slow
  • From: Mario Splivalo
• Re: SELECT INTO large FKyed table is slow
  • From: Pierre C
• Re: SELECT INTO large FKyed table is slow
  • From: Mladen Gogala
• Re: SELECT INTO large FKyed table is slow
  • From: Mladen Gogala
• Re: SELECT INTO large FKyed table is slow
  • From: Kevin Grittner
• Re: SELECT INTO large FKyed table is slow
  • From: Kenneth Marshall
• Re: SELECT INTO large FKyed table is slow
  • From: Mladen Gogala
• Re: Clarification, please
  • From: Kevin Grittner
• Re: Clarification, please
  • From: Mladen Gogala
• Re: SELECT INTO large FKyed table is slow
  • From: Mario Splivalo
• Re: Clarification, please
  • From: Richard Broersma
• Clarification, please
  • From: Mladen Gogala
• Re: SELECT INTO large FKyed table is slow
  • From: Mladen Gogala
• Re: BBU Cache vs. spindles
  • From: Bruce Momjian
• Re: tidscan not work ? Pg 8.4.5 + WinXP
  • From: pasman pasmański
• Re: SELECT INTO large FKyed table is slow
  • From: Pierre C
• Re: SELECT INTO large FKyed table is slow
  • From: Pierre C
• Re: BBU Cache vs. spindles
  • From: Pierre C
• Re: SELECT INTO large FKyed table is slow
  • From: Mario Splivalo
• Re: SELECT INTO large FKyed table is slow
  • From: Mario Splivalo
• Re: BBU Cache vs. spindles
  • From: Bruce Momjian
• Re: BBU Cache vs. spindles
  • From: Bruce Momjian
• Re: BBU Cache vs. spindles
  • From: Bruce Momjian
• Re: SELECT INTO large FKyed table is slow
  • From: Joshua D. Drake
• Re: Question about subselect/IN performance
  • From: bricklen
• Re: SELECT INTO large FKyed table is slow
  • From: Pierre C
• Re: SELECT INTO large FKyed table is slow
  • From: Mario Splivalo
• Re: SELECT INTO large FKyed table is slow
  • From: Mark Kirkwood
• Re: Question about subselect/IN performance
  • From: T.H.
• Re: SELECT INTO large FKyed table is slow
  • From: Mario Splivalo
• Re: SELECT INTO large FKyed table is slow
  • From: Mario Splivalo
• Re: Question about subselect/IN performance
  • From: Kevin Grittner
• Re: Simple database, multiple instances?
  • From: Pierre C
• Question about subselect/IN performance
  • From: T.H.
• Re: Simple database, multiple instances?
  • From: Maciek Sakrejda
• Re: postgresql statements are waiting
  • From: Scott Marlowe
• Re: postgresql statements are waiting
  • From: Kevin Grittner
• Re: tidscan not work ? Pg 8.4.5 + WinXP
  • From: Tom Lane
• Re: tidscan not work ? Pg 8.4.5 + WinXP
  • From: Kevin Grittner
• Re: SELECT INTO large FKyed table is slow
  • From: Mladen Gogala
• postgresql statements are waiting
  • From: bakkiya
• Re: Simple database, multiple instances?
  • From: Mario Splivalo
• Re: Simple database, multiple instances?
  • From: Dimitri Fontaine
• tidscan not work ? Pg 8.4.5 + WinXP
  • From: pasman pasmański
• Re: MVCC performance issue
  • From: Robert Haas
• Re: SELECT INTO large FKyed table is slow
  • From: Pierre C
• Re: SELECT INTO large FKyed table is slow
  • From: Pierre C
• Re: Full Text index is not using during OR operation
  • From: Oleg Bartunov
• Re: Full Text index is not using during OR operation
  • From: Tobias Brox
• Re: Full Text index is not using during OR operation
  • From: AI Rumman
• Re: Full Text index is not using during OR operation
  • From: Oleg Bartunov
• Re: SELECT INTO large FKyed table is slow
  • From: Mario Splivalo
• Re: SELECT INTO large FKyed table is slow
  • From: Mario Splivalo
• Re: SELECT INTO large FKyed table is slow
  • From: Mark Kirkwood
• Full Text index is not using during OR operation
  • From: AI Rumman
• Re: Hi- Sleeptime reduction
  • From: Kevin Grittner
• Hi- Sleeptime reduction
  • From: aaliya zarrin
• Re: SELECT INTO large FKyed table is slow
  • From: Pierre C
• Re: SELECT INTO large FKyed table is slow
  • From: Mario Splivalo
• Re: SELECT INTO large FKyed table is slow
  • From: Pierre C
• SELECT INTO large FKyed table is slow
  • From: Mario Splivalo
• Simple database, multiple instances?
  • From: Mario Splivalo
• Re: CPUs for new databases
  • From: Greg Smith
• Re: CPUs for new databases
  • From: Kevin Grittner
• Re: CPUs for new databases
  • From: Christian Elmerot @ One.com
• Re: Update problem on large table
  • From: bricklen
• Re: Optimizing query
  • From: pasman pasmański
• Update problem on large table
  • From: felix
• Re: Which gives good performance? separate database vs separate schema
  • From: Robert Klemme
• Re: Optimizing query
  • From: Pierre C
• Re: Performance under contention
  • From: Ivan Voras
• Re: Performance under contention
  • From: Greg Smith
• Re: Which gives good performance? separate database vs separate schema
  • From: tv
• Re: Which gives good performance? separate database vs separate schema
  • From: Divakar Singh
• Re: Performance under contention
  • From: Ivan Voras
• Re: Which gives good performance? separate database vs separate schema
  • From: tv
• Re: Which gives good performance? separate database vs separate schema
  • From: Andres Freund
• Re: Which gives good performance? separate database vs separate schema
  • From: tv
• Re: Which gives good performance? separate database vs separate schema
  • From: tv
• Re: Which gives good performance? separate database vs separate schema
  • From: Thomas Kellerer
• Which gives good performance? separate database vs separate schema
  • From: Divakar Singh
• problem with from_collapse_limit and joined views
  • From: Markus Schulz
• Optimizing query
  • From: pasman pasmański
• Re: Performance under contention
  • From: Kevin Grittner
• Re: Performance under contention
  • From: Vitalii Tymchyshyn
• Re: postmaster consuming /lots/ of memory with hash aggregate. why?
  • From: Robert Haas
• Re: Performance under contention
  • From: Ivan Voras
• Re: Performance under contention
  • From: Craig Ringer
• Re: Query Performance SQL Server vs. Postgresql
  • From: Merlin Moncure
• Re: Query Performance SQL Server vs. Postgresql
  • From: Humair Mohammed
• Re: Performance under contention
  • From: Kevin Grittner
• Re: Performance under contention
  • From: Ivan Voras
• Re: Performance under contention
  • From: Kevin Grittner
• Re: Slow SELECT on small table
  • From: Kevin Grittner
• Re: Query Performance SQL Server vs. Postgresql
  • From: tv
• Re: Query Performance SQL Server vs. Postgresql
  • From: Samuel Gendler
• Re: Query Performance SQL Server vs. Postgresql
  • From: tv
• Re: Performance under contention
  • From: Omar Kilani
• Slow SELECT on small table
  • From: Martin Boese
• Re: Query Performance SQL Server vs. Postgresql
  • From: Humair Mohammed
• Re: Query Performance SQL Server vs. Postgresql
  • From: Humair Mohammed
• Re: autovacuum blocks the operations of other manual vacuum
  • From: kuopo
• Re: autovacuum blocks the operations of other manual vacuum
  • From: kuopo
• Re: Performance under contention
  • From: Jignesh Shah
• Re: Performance under contention
  • From: Ivan Voras
• Re: Performance under contention
  • From: Kevin Grittner
• Performance under contention
  • From: Ivan Voras
• Re: Query Performance SQL Server vs. Postgresql
  • From: Robert Haas
• Re: Query Performance SQL Server vs. Postgresql
  • From: Tom Lane
• Re: autovacuum blocks the operations of other manual vacuum
  • From: Alvaro Herrera
• Re: Query Performance SQL Server vs. Postgresql
  • From: tv
• Re: Should changing offset in LIMIT change query plan (at all/so early)?
  • From: Kevin Grittner
• Re: Query Performance SQL Server vs. Postgresql
  • From: tv
• Re: Query Performance SQL Server vs. Postgresql
  • From: tv
• Re: Query Performance SQL Server vs. Postgresql
  • From: Kevin Grittner
• Re: Query Performance SQL Server vs. Postgresql
  • From: Pavel Stehule
• Re: Query Performance SQL Server vs. Postgresql
  • From: tv
• Re: Query Performance SQL Server vs. Postgresql
  • From: Pavel Stehule
• Re: Query Performance SQL Server vs. Postgresql
  • From: Humair Mohammed
• Re: Query Performance SQL Server vs. Postgresql
  • From: Humair Mohammed
• Should changing offset in LIMIT change query plan (at all/so early)?
  • From: goran
• Re: Query Performance SQL Server vs. Postgresql
  • From: Pavel Stehule
• Re: best db schema for time series data?
  • From: Bob Lunney
• Re: How to achieve sustained disk performance of 1.25 GB write for 5 mins
  • From: Dimitri
• Re: autovacuum blocks the operations of other manual vacuum
  • From: tv
• Re: autovacuum blocks the operations of other manual vacuum
  • From: Alvaro Herrera
• Re: best db schema for time series data?
  • From: Robert Klemme
• Re: best db schema for time series data?
  • From: Chris Browne
• Re: Defaulting wal_sync_method to fdatasync on Linux for 9.1?
  • From: Jignesh Shah