Postgres Performance Date Index
[Prev Page][Next Page]
- Re: Query completed in < 1s in PG 9.1 and ~ 700s in PG 9.2
- From: Rodrigo Rosenfeld Rosas
- Re: [HACKERS] pg_dump and thousands of schemas
- Re: HT on or off for E5-26xx ?
- HT on or off for E5-26xx ?
- Re: Query completed in < 1s in PG 9.1 and ~ 700s in PG 9.2
- Re: Query completed in < 1s in PG 9.1 and ~ 700s in PG 9.2
- Re: Query completed in < 1s in PG 9.1 and ~ 700s in PG 9.2
- Re: Re: Increasing work_mem and shared_buffers on Postgres 9.2 significantly slows down queries
- From: Gunnar "Nick" Bluth
- Re: Re: Increasing work_mem and shared_buffers on Postgres 9.2 significantly slows down queries
- From: Gunnar "Nick" Bluth
- Re: Query completed in < 1s in PG 9.1 and ~ 700s in PG 9.2
- Re: Re: Increasing work_mem and shared_buffers on Postgres 9.2 significantly slows down queries
- From: Gunnar "Nick" Bluth
- Re: Query completed in < 1s in PG 9.1 and ~ 700s in PG 9.2
- From: Rodrigo Rosenfeld Rosas
- Re: Query completed in < 1s in PG 9.1 and ~ 700s in PG 9.2
- Re: Re: Increasing work_mem and shared_buffers on Postgres 9.2 significantly slows down queries
- From: Gunnar "Nick" Bluth
- Re: Query completed in < 1s in PG 9.1 and ~ 700s in PG 9.2
- From: Rodrigo Rosenfeld Rosas
- Re: Query completed in < 1s in PG 9.1 and ~ 700s in PG 9.2
- Re: Query completed in < 1s in PG 9.1 and ~ 700s in PG 9.2
- From: Rodrigo Rosenfeld Rosas
- Re: Query completed in < 1s in PG 9.1 and ~ 700s in PG 9.2
- From: Rodrigo Rosenfeld Rosas
- Re: Query completed in < 1s in PG 9.1 and ~ 700s in PG 9.2
- From: Rodrigo Rosenfeld Rosas
- Re: Query completed in < 1s in PG 9.1 and ~ 700s in PG 9.2
- Re: [HACKERS] pg_dump and thousands of schemas
- Re: Query completed in < 1s in PG 9.1 and ~ 700s in PG 9.2
- Re: Query completed in < 1s in PG 9.1 and ~ 700s in PG 9.2
- Query completed in < 1s in PG 9.1 and ~ 700s in PG 9.2
- From: Rodrigo Rosenfeld Rosas
- Re: [HACKERS] pg_dump and thousands of schemas
- Re: help with too slow query
- Re: [HACKERS] pg_dump and thousands of schemas
- Re: help with too slow query
- Re: help with too slow query
- Re: [HACKERS] pg_dump and thousands of schemas
- Re: help with too slow query
- Re: help with too slow query
- From: Pedro Jiménez Pérez
- Re: How to keep queries low latency as concurrency increases
- Re: How to keep queries low latency as concurrency increases
- Re: How to keep queries low latency as concurrency increases
- Re: How to keep queries low latency as concurrency increases
- Re: How to keep queries low latency as concurrency increases
- Re: Constraint exclusion in views
- Re: Re: Increasing work_mem and shared_buffers on Postgres 9.2 significantly slows down queries
- Re: Re: Increasing work_mem and shared_buffers on Postgres 9.2 significantly slows down queries
- Re: [HACKERS] out of memory
- Re: Re: Increasing work_mem and shared_buffers on Postgres 9.2 significantly slows down queries
- Re: Re: Increasing work_mem and shared_buffers on Postgres 9.2 significantly slows down queries
- Re: Re: Increasing work_mem and shared_buffers on Postgres 9.2 significantly slows down queries
- Re: dbt2 performance regresses from 9.1.6 to 9.2.1
- freebsd or linux
- Re: Re: Increasing work_mem and shared_buffers on Postgres 9.2 significantly slows down queries
- Re: Re: Increasing work_mem and shared_buffers on Postgres 9.2 significantly slows down queries
- help with too slow query
- From: Pedro Jiménez Pérez
- Re: dbt2 performance regresses from 9.1.6 to 9.2.1
- Re: Increasing work_mem and shared_buffers on Postgres 9.2 significantly slows down queries
- Re: help with too slow query
- Re: Re: Increasing work_mem and shared_buffers on Postgres 9.2 significantly slows down queries
- Re: help with too slow query
- Re: Re: Increasing work_mem and shared_buffers on Postgres 9.2 significantly slows down queries
- DBT-1
- DBT-1
- Re: Suggested test points for a performance tool?
- Suggested test points for a performance tool?
- Re: Constraint exclusion in views
- Re: Re: Increasing work_mem and shared_buffers on Postgres 9.2 significantly slows down queries
- From: Gunnar "Nick" Bluth
- Re: How to keep queries low latency as concurrency increases
- Re: Constraint exclusion in views
- Re: Constraint exclusion in views
- Re: Re: Increasing work_mem and shared_buffers on Postgres 9.2 significantly slows down queries
- From: Gunnar "Nick" Bluth
- Re: Re: Increasing work_mem and shared_buffers on Postgres 9.2 significantly slows down queries
- From: Gunnar "Nick" Bluth
- Constraint exclusion in views
- Re: dbt2 performance regresses from 9.1.6 to 9.2.1
- Re: High %SYS CPU usage
- Re: Increasing work_mem and shared_buffers on Postgres 9.2 significantly slows down queries
- Re: Re: Increasing work_mem and shared_buffers on Postgres 9.2 significantly slows down queries
- From: Gunnar "Nick" Bluth
- Re: pg_buffercache
- dbt2 performance regresses from 9.1.6 to 9.2.1
- pg_buffercache
- Re: Replaying 48 WAL files takes 80 minutes
- Re: Prepared statements slow in 9.2 still (bad query plan)
- Re: Re: Increasing work_mem and shared_buffers on Postgres 9.2 significantly slows down queries
- Increasing work_mem and shared_buffers on Postgres 9.2 significantly slows down queries
- Re: Increasing work_mem and shared_buffers on Postgres 9.2 significantly slows down queries
- Re: Replaying 48 WAL files takes 80 minutes
- dbt2 performance regresses from 9.1.6 to 9.2.1
- Re: How to keep queries low latency as concurrency increases
- Re: How to keep queries low latency as concurrency increases
- Re: Slow query, where am I going wrong?
- Re: Slow query, where am I going wrong?
- Re: Seq scan on big table, episode 2
- Re: Seq scan on big table, episode 2
- Re: Slow query, where am I going wrong?
- Seq scan on big table, episode 2
- Re: Invalid memory alloc request size
- Re: Invalid memory alloc request size
- Invalid memory alloc request size
- Re: Slow query, where am I going wrong?
- Re: Slow query, where am I going wrong?
- Re: Slow query, where am I going wrong?
- Re: How to keep queries low latency as concurrency increases
- Re: How to keep queries low latency as concurrency increases
- Re: How to keep queries low latency as concurrency increases
- Re: set-returning calls and overhead
- Re: How to keep queries low latency as concurrency increases
- Re: High %SYS CPU usage
- Re: Seq scan on 10million record table.. why?
- Re: Slow query, where am I going wrong?
- Re: PostgreSQL server failed to start
- Re: Slow query, where am I going wrong?
- Re: Seq scan on 10million record table.. why?
- Re: How to keep queries low latency as concurrency increases
- Re: Seq scan on 10million record table.. why?
- Re: Seq scan on 10million record table.. why?
- Re: Replaying 48 WAL files takes 80 minutes
- Re: Replaying 48 WAL files takes 80 minutes
- Re: Replaying 48 WAL files takes 80 minutes
- Re: Replaying 48 WAL files takes 80 minutes
- High %SYS CPU usage
- Seq scan on 10million record table.. why?
- Re: How to keep queries low latency as concurrency increases
- Re: out of memory
- Re: Replaying 48 WAL files takes 80 minutes
- Re: Slow query, where am I going wrong?
- PostgreSQL server failed to start
- out of memory
- Re: Request for help with slow query
- Re: Replaying 48 WAL files takes 80 minutes
- Re: Slow query, where am I going wrong?
- Slow query, where am I going wrong?
- How to keep queries low latency as concurrency increases
- Re: Slower Performance on Postgres 9.1.6 vs 8.2.11
- Re: Request for help with slow query
- Re: Request for help with slow query
- Re: Request for help with slow query
- Re: Request for help with slow query
- Re: Request for help with slow query
- Re: Request for help with slow query
- Re: Setting Statistics on Functional Indexes
- Re: Request for help with slow query
- Request for help with slow query
- Re: Replaying 48 WAL files takes 80 minutes
- Re: Tons of free RAM. Can't make it go away.
- Re: Setting Statistics on Functional Indexes
- Re: Replaying 48 WAL files takes 80 minutes
- Re: Replaying 48 WAL files takes 80 minutes
- Re: Prepared statements slow in 9.2 still (bad query plan)
- Re: Replaying 48 WAL files takes 80 minutes
- Replaying 48 WAL files takes 80 minutes
- Re: How to upgrade from 9.1 to 9.2 with replication?
- From: Matheus de Oliveira
- Re: How to upgrade from 9.1 to 9.2 with replication?
- Re: How to upgrade from 9.1 to 9.2 with replication?
- From: Matheus de Oliveira
- Re: How to upgrade from 9.1 to 9.2 with replication?
- Re: How to upgrade from 9.1 to 9.2 with replication?
- From: Matheus de Oliveira
- Re: How to upgrade from 9.1 to 9.2 with replication?
- Re: How to upgrade from 9.1 to 9.2 with replication?
- Re: Prepared statements slow in 9.2 still (bad query plan)
- Prepared statements slow in 9.2 still (bad query plan)
- Re: How to upgrade from 9.1 to 9.2 with replication?
- Re: Tons of free RAM. Can't make it go away.
- Re: Slower Performance on Postgres 9.1.6 vs 8.2.11
- Re: Setting Statistics on Functional Indexes
- Re: Setting Statistics on Functional Indexes
- Re: Setting Statistics on Functional Indexes
- Re: Setting Statistics on Functional Indexes
- Re: Setting Statistics on Functional Indexes
- Re: Slower Performance on Postgres 9.1.6 vs 8.2.11
- Re: Slower Performance on Postgres 9.1.6 vs 8.2.11
- Re: Query-Planer from 6seconds TO DAYS
- Re: Slower Performance on Postgres 9.1.6 vs 8.2.11
- Re: Setting Statistics on Functional Indexes
- Re: Setting Statistics on Functional Indexes
- Slower Performance on Postgres 9.1.6 vs 8.2.11
- Re: Query-Planer from 6seconds TO DAYS
- Re: Query-Planer from 6seconds TO DAYS
- PSA: New Kernels and intel_idle cpuidle Driver!
- Re: Query-Planer from 6seconds TO DAYS
- Re: Query-Planer from 6seconds TO DAYS
- Re: Query-Planer from 6seconds TO DAYS
- Re: Query-Planer from 6seconds TO DAYS
- Re: Query-Planer from 6seconds TO DAYS
- Re: Query-Planer from 6seconds TO DAYS
- BAD performance with enable_bitmapscan = on with Postgresql 9.0.X (X = 3 and 10)
- Re: Query-Planer from 6seconds TO DAYS
- Re: Query-Planer from 6seconds TO DAYS
- Re: Query-Planer from 6seconds TO DAYS
- Re: Query-Planer from 6seconds TO DAYS
- Re: Query-Planer from 6seconds TO DAYS
- Re: How to upgrade from 9.1 to 9.2 with replication?
- Re: How to upgrade from 9.1 to 9.2 with replication?
- Re: How to upgrade from 9.1 to 9.2 with replication?
- Re: Out of shared mem on new box with more mem, 9.1.5 -> 9.1.6
- Re: Setting Statistics on Functional Indexes
- Re: Setting Statistics on Functional Indexes
- Re: Setting Statistics on Functional Indexes
- Re: Query-Planer from 6seconds TO DAYS
- Setting Statistics on Functional Indexes
- Query-Planer from 6seconds TO DAYS
- Re: Query with limit goes from few ms to hours
- Re: Query with limit goes from few ms to hours
- Re: Tons of free RAM. Can't make it go away.
- Re: Tons of free RAM. Can't make it go away.
- Re: Tons of free RAM. Can't make it go away.
- Re: Tons of free RAM. Can't make it go away.
- Re: Tons of free RAM. Can't make it go away.
- Re: Tons of free RAM. Can't make it go away.
- From: Franklin, Dan (FEN)
- Re: Tons of free RAM. Can't make it go away.
- Re: Tons of free RAM. Can't make it go away.
- Re: Tons of free RAM. Can't make it go away.
- Re: Tons of free RAM. Can't make it go away.
- Re: Tons of free RAM. Can't make it go away.
- Re: Tons of free RAM. Can't make it go away.
- Tons of free RAM. Can't make it go away.
- Re: Connection Options -- SSL already uses compression?
- Connection Options -- SSL already uses compression?
- How to upgrade from 9.1 to 9.2 with replication?
- Re: Recursive query gets slower when adding an index
- Re: How to upgrade from 9.1 to 9.2 with replication?
- Re: How to upgrade from 9.1 to 9.2 with replication?
- Re: How to upgrade from 9.1 to 9.2 with replication?
- Re: Tablespace-derived stats?
- Re: limit order by performance issue
- Re: Tablespace-derived stats?
- Re: Tablespace-derived stats?
- Re: Tablespace-derived stats?
- Re: How to upgrade from 9.1 to 9.2 with replication?
- Re: Tablespace-derived stats?
- Tablespace-derived stats?
- Re: How to upgrade from 9.1 to 9.2 with replication?
- Re: limit order by performance issue
- From: Pedro Jiménez Pérez
- Re: Recursive query gets slower when adding an index
- Re: SELECT AND AGG huge tables
- Recursive query gets slower when adding an index
- Re: shared_buffers/effective_cache_size on 96GB server
- Re: shared_buffers/effective_cache_size on 96GB server
- Re: shared_buffers/effective_cache_size on 96GB server
- Re: shared_buffers/effective_cache_size on 96GB server
- Re: shared_buffers/effective_cache_size on 96GB server
- Re: Unused index influencing sequential scan plan
- Re: Unused index influencing sequential scan plan
- Re: Unused index influencing sequential scan plan
- Re: Unused index influencing sequential scan plan
- Re: Unused index influencing sequential scan plan
- Re: Two identical systems, radically different performance
- Re: Unused index influencing sequential scan plan
- Re: Unused index influencing sequential scan plan
- Re: Unused index influencing sequential scan plan
- Re: Unused index influencing sequential scan plan
- Re: Unused index influencing sequential scan plan
- Unused index influencing sequential scan plan
- Re: Two identical systems, radically different performance
- Re: LIKE op with B-Tree Index?
- Re: LIKE op with B-Tree Index?
- Re: LIKE op with B-Tree Index?
- Re: Two identical systems, radically different performance
- Re: Two identical systems, radically different performance
- Re: Out of shared mem on new box with more mem, 9.1.5 -> 9.1.6
- Re: Out of shared mem on new box with more mem, 9.1.5 -> 9.1.6
- High cost estimates when n_distinct is set
- Re: SELECT AND AGG huge tables
- Re: Out of shared mem on new box with more mem, 9.1.5 -> 9.1.6
- Re: Out of shared mem on new box with more mem, 9.1.5 -> 9.1.6
- Re: have: seq scan - want: index scan
- Re: Out of shared mem on new box with more mem, 9.1.5 -> 9.1.6
- Out of shared mem on new box with more mem, 9.1.5 -> 9.1.6
- have: seq scan - want: index scan
- pgbounce max_client_conn and default_pool_size
- Re: Slow Delete : Seq scan instead of index scan
- Re: LIKE op with B-Tree Index?
- Re: Have: Seq Scan - Want: Index Scan - what am I doing wrong?
- Re: Have: Seq Scan - Want: Index Scan - what am I doing wrong?
- Re: Have: Seq Scan - Want: Index Scan - what am I doing wrong?
- Re: Have: Seq Scan - Want: Index Scan - what am I doing wrong?
- Have: Seq Scan - Want: Index Scan - what am I doing wrong?
- Re: limit order by performance issue
- Re: LIKE op with B-Tree Index?
- LIKE op with B-Tree Index?
- Re: limit order by performance issue
- Re: limit order by performance issue
- Re: limit order by performance issue
- limit order by performance issue
- Re: Guide to Posting Slow Query Questions
- Re: Support Create package
- Re: Support Create package
- Support Create package
- LIKE op with B-Tree Index?
- Re: Slow Delete : Seq scan instead of index scan
- Slow Delete : Seq scan instead of index scan
- Re: Slow Delete : Seq scan instead of index scan
- Re: Slow Delete : Seq scan instead of index scan
- Re: Slow Delete : Seq scan instead of index scan
- Re: Slow Delete : Seq scan instead of index scan
- Re: Two identical systems, radically different performance
- Re: SELECT AND AGG huge tables
- Re: SELECT AND AGG huge tables
- Re: SELECT AND AGG huge tables
- Re: SELECT AND AGG huge tables
- Re: SELECT AND AGG huge tables
- From: Matheus de Oliveira
- Re: SELECT AND AGG huge tables
- SELECT AND AGG huge tables
- Re: Query with limit goes from few ms to hours
- Re: Two identical systems, radically different performance
- Re: Two identical systems, radically different performance
- Re: Two identical systems, radically different performance
- Re: Two identical systems, radically different performance
- Re: Two identical systems, radically different performance
- Re: Two identical systems, radically different performance
- Re: Two identical systems, radically different performance
- Re: Two identical systems, radically different performance
- Re: Two identical systems, radically different performance
- Re: Query with limit goes from few ms to hours
- Re: problems with large objects dump
- From: Sergio Gabriel Rodriguez
- WebSphere Application Server support for postgres
- Re: Two identical systems, radically different performance
- Re: Query with limit goes from few ms to hours
- Re: Index over all partitions (aka global index)?
- Re: Query with limit goes from few ms to hours
- Query with limit goes from few ms to hours
- Re: Index over all partitions (aka global index)?
- Index over all partitions (aka global index)?
- Re: Do cast affects index usage?
- Re: problems with large objects dump
- Re: Do cast affects index usage?
- From: Anibal David Acosta
- Re: problems with large objects dump
- Re: problems with large objects dump
- From: Sergio Gabriel Rodriguez
- Re: hash aggregation
- Re: hash aggregation
- Re: Do cast affects index usage?
- Re: Do cast affects index usage?
- Do cast affects index usage?
- From: Anibal David Acosta
- Re: hash aggregation
- Re: hash aggregation
- Re: hash aggregation
- Re: hash aggregation
- Re: hash aggregation
- Re: hash aggregation
- Re: problems with large objects dump
- Re: Drawbacks of create index where is not null ?
- Re: problems with large objects dump
- Re: problems with large objects dump
- From: Sergio Gabriel Rodriguez
- Re: shared_buffers/effective_cache_size on 96GB server
- Re: hash aggregation
- Re: hash aggregation
- Re: Two identical systems, radically different performance
- Re: Two identical systems, radically different performance
- Re: Two identical systems, radically different performance
- Re: Drawbacks of create index where is not null ?
- Re: hash aggregation
- Re: Drawbacks of create index where is not null ?
- Re: Drawbacks of create index where is not null ?
- Re: shared_buffers/effective_cache_size on 96GB server
- Re: Drawbacks of create index where is not null ?
- Re: hash aggregation
- Re: hash aggregation
- Re: shared_buffers/effective_cache_size on 96GB server
- Re: shared_buffers/effective_cache_size on 96GB server
- Re: shared_buffers/effective_cache_size on 96GB server
- Re: shared_buffers/effective_cache_size on 96GB server
- Re: hash aggregation
- Re: shared_buffers/effective_cache_size on 96GB server
- Re: shared_buffers/effective_cache_size on 96GB server
- Re: shared_buffers/effective_cache_size on 96GB server
- Re: shared_buffers/effective_cache_size on 96GB server
- Re: Ways to speed up ts_rank
- Re: Ways to speed up ts_rank
- Re: shared_buffers/effective_cache_size on 96GB server
- Re: shared_buffers/effective_cache_size on 96GB server
- Re: Hyperthreading (was: Two identical systems, radically different performance)
- Re: shared_buffers/effective_cache_size on 96GB server
- Re: Hyperthreading (was: Two identical systems, radically different performance)
- Drawbacks of create index where is not null ?
- Re: shared_buffers/effective_cache_size on 96GB server
- hash aggregation
- Re: shared_buffers/effective_cache_size on 96GB server
- Re: shared_buffers/effective_cache_size on 96GB server
- Re: Hyperthreading (was: Two identical systems, radically different performance)
- Re: Hyperthreading (was: Two identical systems, radically different performance)
- Re: Ways to speed up ts_rank
- Re: shared_buffers/effective_cache_size on 96GB server
- Re: shared_buffers/effective_cache_size on 96GB server
- Re: shared_buffers/effective_cache_size on 96GB server
- Re: shared_buffers/effective_cache_size on 96GB server
- Re: shared_buffers/effective_cache_size on 96GB server
- Re: Hyperthreading (was: Two identical systems, radically different performance)
- Re: Ways to speed up ts_rank
- From: François Beausoleil
- Re: shared_buffers/effective_cache_size on 96GB server
- Re: shared_buffers/effective_cache_size on 96GB server
- Re: shared_buffers/effective_cache_size on 96GB server
- Re: shared_buffers/effective_cache_size on 96GB server
- Re: shared_buffers/effective_cache_size on 96GB server
- Re: shared_buffers/effective_cache_size on 96GB server
- Re: shared_buffers/effective_cache_size on 96GB server
- shared_buffers/effective_cache_size on 96GB server
- Re: Why am I getting great/terrible estimates with these CTE queries?
- Re: Hyperthreading (was: Two identical systems, radically different performance)
- Re: Why am I getting great/terrible estimates with these CTE queries?
- Ways to speed up ts_rank
- Why am I getting great/terrible estimates with these CTE queries?
- Re: Two identical systems, radically different performance
- Re: Hyperthreading (was: Two identical systems, radically different performance)
- Re: Scaling 10 million records in PostgreSQL table
- Re: Scaling 10 million records in PostgreSQL table
- Re: Scaling 10 million records in PostgreSQL table
- Re: Two identical systems, radically different performance
- Re: Hyperthreading (was: Two identical systems, radically different performance)
- Re: Hyperthreading (was: Two identical systems, radically different performance)
- Re: Hyperthreading (was: Two identical systems, radically different performance)
- Hyperthreading (was: Two identical systems, radically different performance)
- Re: Two identical systems, radically different performance
- Re: Two identical systems, radically different performance
- Re: Two identical systems, radically different performance
- Re: Two identical systems, radically different performance
- Re: Two identical systems, radically different performance
- Re: Two identical systems, radically different performance
- Re: Two identical systems, radically different performance
- Re: Two identical systems, radically different performance
- Re: Two identical systems, radically different performance
- Re: Two identical systems, radically different performance
- Re: Two identical systems, radically different performance
- Re: Two identical systems, radically different performance
- Re: Two identical systems, radically different performance
- Re: Scaling 10 million records in PostgreSQL table
- Re: Two identical systems, radically different performance
- Re: Two identical systems, radically different performance
- Re: Two identical systems, radically different performance
- Re: Two identical systems, radically different performance
- Re: Two identical systems, radically different performance
- Re: Two identical systems, radically different performance
- Re: Two identical systems, radically different performance
- Re: Two identical systems, radically different performance
- Re: Two identical systems, radically different performance
- Re: Two identical systems, radically different performance
- Re: Two identical systems, radically different performance
- Re: Two identical systems, radically different performance
- Re: Two identical systems, radically different performance
- Two identical systems, radically different performance
- Re: Scaling 10 million records in PostgreSQL table
- Re: Scaling 10 million records in PostgreSQL table
- Re: Scaling 10 million records in PostgreSQL table
- Re: Scaling 10 million records in PostgreSQL table
- Re: Scaling 10 million records in PostgreSQL table
- Scaling 10 million records in PostgreSQL table
- Re: Strange behavior after upgrade from 9.0 to 9.2
- Re: Strange behavior after upgrade from 9.0 to 9.2
- Re: Strange behavior after upgrade from 9.0 to 9.2
- Re: Strange behavior after upgrade from 9.0 to 9.2
- Re: Guide to Posting Slow Query Questions
- Re: [repost] Help me develop new commit_delay advice
- Re: Same query doing slow then quick
- Re: UPDATE execution time is increasing
- From: Valentine Gogichashvili
- UPDATE execution time is increasing
- Re: Strange behavior after upgrade from 9.0 to 9.2
- Re: Strange behavior after upgrade from 9.0 to 9.2
- Re: Same query doing slow then quick
- Strange behavior after upgrade from 9.0 to 9.2
- hash aggregation speedup
- Re: how to avoid deadlock on masive update with multiples delete
- From: Anibal David Acosta
- Re: how to avoid deadlock on masive update with multiples delete
- Re: how to avoid deadlock on masive update with multiples delete
- Re: how to avoid deadlock on masive update with multiples delete
- Re: how to avoid deadlock on masive update with multiples delete
- Re: how to avoid deadlock on masive update with multiples delete
- Re: how to avoid deadlock on masive update with multiples delete
- Re: how to avoid deadlock on masive update with multiples delete
- Re: how to avoid deadlock on masive update with multiples delete
- Re: how to avoid deadlock on masive update with multiples delete
- Re: how to avoid deadlock on masive update with multiples delete
- Re: A Tale of 2 algorithms
- Re: how to avoid deadlock on masive update with multiples delete
- how to avoid deadlock on masive update with multiples delete
- From: Anibal David Acosta
- Re: Inserts in 'big' table slowing down the database
- Re: Postgres becoming slow, only full vacuum fixes it
- Re: hardware advice
- Re: 20% performance drop on PostgreSQL 9.2 from kernel 3.5.3 to 3.6-rc5 on AMD chipsets
- Re: suboptimal query plan
- Re: suboptimal query plan
- suboptimal query plan
- Re: hardware advice - opinions about HP?
- Re: hardware advice - opinions about HP?
- Re: hardware advice
- Re: Inserts in 'big' table slowing down the database
- Re: hardware advice - opinions about HP?
- From: Franklin, Dan (FEN)
- Re: deadlock_timeout affect on performance
- Re: hardware advice
- deadlock_timeout affect on performance
- Re: Spurious failure to obtain row lock possible in PG 9.1?
- Re: A Tale of 2 algorithms
- Re: Inserts in 'big' table slowing down the database
- Re: Inserts in 'big' table slowing down the database
- Re: NestedLoops over BitmapScan question
- A Tale of 2 algorithms
- Re: Postgres becoming slow, only full vacuum fixes it
- Re: Postgres becoming slow, only full vacuum fixes it
- wrong join result set estimate
- Re: [GENERAL] Inaccurate Explain Cost
- Re: Postgres becoming slow, only full vacuum fixes it
- Re: hardware advice
- NestedLoops over BitmapScan question
- Re: Query plan, nested EXISTS
- Re: Possible Performance Regression with Transitive Comparisons vs. Constants
- Re: Query plan, nested EXISTS
- Re: Query plan, nested EXISTS
- Re: Possible Performance Regression with Transitive Comparisons vs. Constants
- Query plan, nested EXISTS
- Re: Possible Performance Regression with Transitive Comparisons vs. Constants
- Possible Performance Regression with Transitive Comparisons vs. Constants
- Re: hardware advice
- Re: hardware advice
- Re: hardware advice
- Re: hardware advice
- Re: "Select * " on 12-18M row table from remote machine thru JDBC - Performance nose-dives after 10M-ish records
- "Select * " on 12-18M row table from remote machine thru JDBC - Performance nose-dives after 10M-ish records
- Re: [PERFORM] Re: [PERFORM] exponential performance decrease, problem with version postgres + RHEL?
- RE: [PERFORM] exponential performance decrease, problem with version postgres + RHEL?
- Re: [PERFORM] exponential performance decrease, problem with version postgres + RHEL?
- exponential performance decrease, problem with version postgres + RHEL?
- Re: hardware advice
- Re: Postgres becoming slow, only full vacuum fixes it
- Re: hardware advice
- Re: hardware advice
- Re: hardware advice
- Re: hardware advice
- Re: hardware advice
- Re: hardware advice
- Re: hardware advice
- Re: hardware advice
- Re: hardware advice
- Re: hardware advice
- Re: hardware advice
- Re: hardware advice
- Re: hardware advice
- Re: hardware advice
- Re: hardware advice
- Re: hardware advice
- Re: hardware advice
- Re: hardware advice
- Re: hardware advice
- Re: hardware advice
- Re: hardware advice
- Re: hardware advice
- Re: hardware advice
- Re: hardware advice
- Re: hardware advice
- Re: hardware advice
- Re: hardware advice
- Re: hardware advice
- Re: hardware advice
- Re: hardware advice
- Re: hardware advice
- Re: hardware advice
- hardware advice
- Re: Same query doing slow then quick
- Re: Same query doing slow then quick
- Re: [GENERAL] Inaccurate Explain Cost
- Re: Inaccurate Explain Cost
- Re: [GENERAL] Memory issues
- Re: [GENERAL] Memory issues
- Re: [GENERAL] Memory issues
- Re: [GENERAL] Memory issues
- Re: [GENERAL] Memory issues
- Re: Inaccurate Explain Cost
- From: hubert depesz lubaczewski
- Re: Inaccurate Explain Cost
- Re: Guide to Posting Slow Query Questions
- Inaccurate Explain Cost
- Re: Same query doing slow then quick
- Re: Same query doing slow then quick
- Re: Same query doing slow then quick
- Re: Same query doing slow then quick
- Re: Same query doing slow then quick
- Re: Same query doing slow then quick
- Re: Same query doing slow then quick
- Re: Same query doing slow then quick
- Re: Same query doing slow then quick
- Re: Same query doing slow then quick
- Re: Same query doing slow then quick
- Re: Same query doing slow then quick
- Re: Same query doing slow then quick
- Re: Postgres becoming slow, only full vacuum fixes it
- Re: Same query doing slow then quick
- Re: Same query doing slow then quick
- Re: Same query doing slow then quick
- Re: Postgres becoming slow, only full vacuum fixes it
- Same query doing slow then quick
- Re: Postgres becoming slow, only full vacuum fixes it
- Re: Postgres becoming slow, only full vacuum fixes it
- Re: Postgres becoming slow, only full vacuum fixes it
- Re: Postgres becoming slow, only full vacuum fixes it
- Re: Postgres becoming slow, only full vacuum fixes it
- Re: Postgres becoming slow, only full vacuum fixes it
- Re: Spurious failure to obtain row lock possible in PG 9.1?
- Spurious failure to obtain row lock possible in PG 9.1?
- Re: Postgres becoming slow, only full vacuum fixes it
- Re: Postgres becoming slow, only full vacuum fixes it
- Re: Postgres becoming slow, only full vacuum fixes it
- Re: Postgres becoming slow, only full vacuum fixes it
- Re: Postgres becoming slow, only full vacuum fixes it
- Re: Postgres becoming slow, only full vacuum fixes it
- Re: Postgres becoming slow, only full vacuum fixes it
- Re: Postgres becoming slow, only full vacuum fixes it
- Re: Postgres becoming slow, only full vacuum fixes it
- Re: Postgres becoming slow, only full vacuum fixes it
- Postgres becoming slow, only full vacuum fixes it
- Re: Cost of opening and closing an empty transaction
- Memory issues
- Re: Newbie performance problem - semop taking most of time ?
- Re: Newbie performance problem - semop taking most of time ?
- Re: wal_sync_method on FreeBSD 9.0 - ZFS
- Re: Newbie performance problem - semop taking most of time ?
- Re: Cost of opening and closing an empty transaction
- Re: wal_sync_method on FreeBSD 9.0 - ZFS
- PostgreSQL performance on 64 bit as compared to 32 bit
- Re: PostgreSQL performance on 64 bit as compared to 32 bit
- Cost of opening and closing an empty transaction
- Newbie performance problem - semop taking most of time ?
- Query Planner Optimization?
- Re: problems with large objects dump
- Re: problems with large objects dump
- From: Sergio Gabriel Rodriguez
- Re: problems with large objects dump
- problems with large objects dump
- From: Sergio Gabriel Rodriguez
- Re: 20% performance drop on PostgreSQL 9.2 from kernel 3.5.3 to 3.6-rc5 on AMD chipsets
- Re: 20% performance drop on PostgreSQL 9.2 from kernel 3.5.3 to 3.6-rc5 on AMD chipsets
- Re: 20% performance drop on PostgreSQL 9.2 from kernel 3.5.3 to 3.6-rc5 on AMD chipsets
- Re: Planner selects different execution plans depending on limit
- Re: Are there known performance issues with defining all Foreign Keys as deferrable initially immediate
- From: McKinzie, Alan (Alan)
- Re: Are there known performance issues with defining all Foreign Keys as deferrable initially immediate
- Re: Are there known performance issues with defining all Foreign Keys as deferrable initially immediate
- Re: Are there known performance issues with defining all Foreign Keys as deferrable initially immediate
- Re: Are there known performance issues with defining all Foreign Keys as deferrable initially immediate
- Re: Remote access to Postgresql slow
- Re: Remote access to Postgresql slow
- Remote access to Postgresql slow
- Re: Setting autovacuum_vacuum_scale_factor to 0 a good idea ?
- Re: Setting autovacuum_vacuum_scale_factor to 0 a good idea ?
- Setting autovacuum_vacuum_scale_factor to 0 a good idea ?
- wal_sync_method on FreeBSD 9.0 - ZFS
- Are there known performance issues with defining all Foreign Keys as deferrable initially immediate
- From: McKinzie, Alan (Alan)
- Re: 20% performance drop on PostgreSQL 9.2 from kernel 3.5.3 to 3.6-rc5 on AMD chipsets
- Re: 20% performance drop on PostgreSQL 9.2 from kernel 3.5.3 to 3.6-rc5 on AMD chipsets
- Re: 20% performance drop on PostgreSQL 9.2 from kernel 3.5.3 to 3.6-rc5 on AMD chipsets
- Re: 20% performance drop on PostgreSQL 9.2 from kernel 3.5.3 to 3.6-rc5 on AMD chipsets
- Re: 20% performance drop on PostgreSQL 9.2 from kernel 3.5.3 to 3.6-rc5 on AMD chipsets
- Re: Guide to Posting Slow Query Questions
- 20% performance drop on PostgreSQL 9.2 from kernel 3.5.3 to 3.6-rc5 on AMD chipsets
- Re: AppScale backend datastore (NoSQL again kind of)
- Re: Linux machine aggressively clearing cache
- Re: AppScale backend datastore (NoSQL again kind of)
- AppScale backend datastore (NoSQL again kind of)
- Re: Planner selects different execution plans depending on limit
- Re: Planner selects different execution plans depending on limit
- Re: Planner selects different execution plans depending on limit
- Re: Planner selects different execution plans depending on limit
- Re: Planner selects different execution plans depending on limit
- Re: Planner selects different execution plans depending on limit
- Re: : PostgreSQL Index behavior
- Re: : PostgreSQL Index behavior
- Re: Planner selects different execution plans depending on limit
- Guide to Posting Slow Query Questions
- Re: : PostgreSQL Index behavior
- Re: : PostgreSQL Index behavior
- Re: Planner selects different execution plans depending on limit
- Re: add column with default value is very slow
- From: hubert depesz lubaczewski
- Re: add column with default value is very slow
- Re: add column with default value is very slow
- Re: add column with default value is very slow
- From: hubert depesz lubaczewski
- Re: add column with default value is very slow
- Re: add column with default value is very slow
- From: hubert depesz lubaczewski
- Re: add column with default value is very slow
- add column with default value is very slow
- Re: Planner selects different execution plans depending on limit
- Re: Slow Performance on a XEON E5504
- Re: Planner selects different execution plans depending on limit
[Index of Archives]
[Postgresql General]
[Postgresql PHP]
[PHP Home]
[PHP on Windows]
[Yosemite]