Postgres Performance Date Index
[Prev Page][Next Page]
- Re: Inserting 8MB bytea: just 25% of disk perf used?
- Re: a heavy duty operation on an "unused" table kills my server
- Inserting 8MB bytea: just 25% of disk perf used?
- From: fkater@xxxxxxxxxxxxxx
- Re: performance config help
- Re: performance config help
- Re: performance config help
- Re: a heavy duty operation on an "unused" table kills my server
- Re: performance config help
- Re: Hashaggregate estimates
- Hashaggregate estimates
- Re: performance config help
- Re: performance config help
- Re: a heavy duty operation on an "unused" table kills my server
- Re: a heavy duty operation on an "unused" table kills my server
- Re: a heavy duty operation on an "unused" table kills my server
- Re: a heavy duty operation on an "unused" table kills my server
- Re: [PERFORMANCE] work_mem vs temp files issue
- Re: [PERFORMANCE] work_mem vs temp files issue
- Re: a heavy duty operation on an "unused" table kills my server
- Re: [PERFORMANCE] work_mem vs temp files issue
- Re: a heavy duty operation on an "unused" table kills my server
- Re: [PERFORMANCE] work_mem vs temp files issue
- Re: [PERFORMANCE] work_mem vs temp files issue
- Re: a heavy duty operation on an "unused" table kills my server
- Re: [PERFORMANCE] work_mem vs temp files issue
- Re: [PERFORMANCE] work_mem vs temp files issue
- Re: [PERFORMANCE] work_mem vs temp files issue
- Re: a heavy duty operation on an "unused" table kills my server
- From: Euler Taveira de Oliveira
- Re: a heavy duty operation on an "unused" table kills my server
- Re: a heavy duty operation on an "unused" table kills my server
- Re: a heavy duty operation on an "unused" table kills my server
- Re: a heavy duty operation on an "unused" table kills my server
- Re: [PERFORMANCE] work_mem vs temp files issue
- Re: a heavy duty operation on an "unused" table kills my server
- Re: a heavy duty operation on an "unused" table kills my server
- Re: a heavy duty operation on an "unused" table kills my server
- Re: a heavy duty operation on an "unused" table kills my server
- Re: performance config help
- a heavy duty operation on an "unused" table kills my server
- Re: performance config help
- Re: performance config help
- Re: performance config help
- Re: performance config help
- Re: performance config help
- Re: performance config help
- From: Pierre Frédéric Caillaud
- Re: performance config help
- Re: performance config help
- Re: performance config help
- Re: Choice of bitmap scan over index scan
- Re: performance config help
- Re: performance config help
- Re: performance config help
- Re: performance config help
- Re: [PERFORMANCE] work_mem vs temp files issue
- Re: performance config help
- Re: [PERFORMANCE] work_mem vs temp files issue
- Re: performance config help
- Re: performance config help
- Re: [PERFORMANCE] work_mem vs temp files issue
- Re: performance config help
- Re: performance config help
- Re: performance config help
- Re: Choice of bitmap scan over index scan
- Re: performance config help
- Re: performance config help
- Re: performance config help
- Re: performance config help
- Re: [PERFORMANCE] work_mem vs temp files issue
- Re: [PERFORMANCE] work_mem vs temp files issue
- Re: [PERFORMANCE] work_mem vs temp files issue
- Re: performance config help
- Re: performance config help
- Re: performance config help
- Re: [PERFORMANCE] work_mem vs temp files issue
- Re: performance config help
- Re: performance config help
- Re: performance config help
- Re: performance config help
- cache false-sharing in lwlocks
- Re: performance config help
- Re: performance config help
- Re: performance config help
- Re: performance config help
- Re: performance config help
- Re: Choice of bitmap scan over index scan
- Re: performance config help
- Re: performance config help
- performance config help
- Re: PG optimization question
- From: Pierre Frédéric Caillaud
- Re: Choice of bitmap scan over index scan
- From: Pierre Frédéric Caillaud
- Re: Choice of bitmap scan over index scan
- Re: Choice of bitmap scan over index scan
- Re: Choice of bitmap scan over index scan
- Re: Choice of bitmap scan over index scan
- Re: PG optimization question
- Re: Choice of bitmap scan over index scan
- Re: Choice of bitmap scan over index scan
- Re: Choice of bitmap scan over index scan
- Re: Choice of bitmap scan over index scan
- Re: Choice of bitmap scan over index scan
- Choice of bitmap scan over index scan
- Re: PG optimization question
- From: Pierre Frédéric Caillaud
- Re: PG optimization question
- Re: PG optimization question
- Re: PG optimization question
- Re: Joint index including MAX() ?
- Re: pg_connect takes 3.0 seconds
- Re: PG optimization question
- From: Pierre Frédéric Caillaud
- Re: PG optimization question
- Re: Joint index including MAX() ?
- Re: Joint index including MAX() ?
- From: Grzegorz Jaśkiewicz
- Re: PG optimization question
- Joint index including MAX() ?
- Re: PG optimization question
- Re: PG optimization question
- Re: PG optimization question
- From: Grzegorz Jaśkiewicz
- PG optimization question
- PG optimization question
- Re: Massive table (500M rows) update nightmare
- From: Pierre Frédéric Caillaud
- Re: Change query join order
- Re: Change query join order
- Re: Change query join order
- Re: Change query join order
- Re: Massive table (500M rows) update nightmare
- Re: Massive table (500M rows) update nightmare
- Change query join order
- From: Kaloyan Iliev Iliev
- Re: Massive table (500M rows) update nightmare
- Re: Massive table (500M rows) update nightmare
- Re: Massive table (500M rows) update nightmare
- Re: Massive table (500M rows) update nightmare
- Re: Array comparison
- Re: Array comparison
- Re: Massive table (500M rows) update nightmare
- Re: Massive table (500M rows) update nightmare
- FusionIO performance
- Re: Massive table (500M rows) update nightmare
- Re: Massive table (500M rows) update nightmare
- Re: Massive table (500M rows) update nightmare
- Array comparison
- Re: Air-traffic benchmark
- Re: Air-traffic benchmark
- Re: Air-traffic benchmark
- Re: "large" spam tables and performance: postgres memory parameters
- Re: "large" spam tables and performance: postgres memory parameters
- Re: Massive table (500M rows) update nightmare
- Re: Air-traffic benchmark
- Re: Massive table (500M rows) update nightmare
- Re: Air-traffic benchmark
- From: hubert depesz lubaczewski
- Re: Air-traffic benchmark
- Re: Air-traffic benchmark
- Re: Air-traffic benchmark
- Re: Massive table (500M rows) update nightmare
- Re: Massive table (500M rows) update nightmare
- Re: noob inheritance question
- Re: query looping?
- Re: pg_connect takes 3.0 seconds
- Re: Joining on text field VS int
- Re: query looping?
- Re: Massive table (500M rows) update nightmare
- Re: Massive table (500M rows) update nightmare
- Re: Air-traffic benchmark
- Re: Air-traffic benchmark
- Re: Air-traffic benchmark
- Re: Air-traffic benchmark
- Re: Massive table (500M rows) update nightmare
- From: Greg Sabino Mullane
- Re: Massive table (500M rows) update nightmare
- Re: "large" spam tables and performance: postgres memory parameters
- Re: Massive table (500M rows) update nightmare
- Re: Massive table (500M rows) update nightmare
- Re: Air-traffic benchmark
- Re: Air-traffic benchmark
- Re: Air-traffic benchmark
- Re: Air-traffic benchmark
- "large" spam tables and performance: postgres memory parameters
- Re: Massive table (500M rows) update nightmare
- Re: Air-traffic benchmark
- Re: Massive table (500M rows) update nightmare
- Re: Air-traffic benchmark
- From: Grzegorz Jaśkiewicz
- Re: Air-traffic benchmark
- Re: Air-traffic benchmark
- Re: Air-traffic benchmark
- Re: Air-traffic benchmark
- Re: Air-traffic benchmark
- Re: Air-traffic benchmark
- Re: Air-traffic benchmark
- Re: Air-traffic benchmark
- Re: Air-traffic benchmark
- Re: Air-traffic benchmark
- Re: Air-traffic benchmark
- From: Arjen van der Meijden
- Re: Air-traffic benchmark
- Re: Massive table (500M rows) update nightmare
- Re: Air-traffic benchmark
- Re: Air-traffic benchmark
- Air-traffic benchmark
- Re: Digesting explain analyze
- Re: Digesting explain analyze
- Re: Massive table (500M rows) update nightmare
- Re: Optimizer use of index slows down query by factor
- Massive table (500M rows) update nightmare
- Re: pg_connect takes 3.0 seconds
- Re: Digesting explain analyze
- Re: Digesting explain analyze
- Joining on text field VS int
- Re: noob inheritance question
- Re: pg_connect takes 3.0 seconds
- Re: pg_connect takes 3.0 seconds
- Re: Digesting explain analyze
- Re: noob inheritance question
- Re: noob inheritance question
- noob inheritance question
- Re: pg_connect takes 3.0 seconds
- Re: pg_connect takes 3.0 seconds
- Re: Digesting explain analyze
- Digesting explain analyze
- Re: pg_connect takes 3.0 seconds
- Re: pg_connect takes 3.0 seconds
- Re: pg_connect takes 3.0 seconds
- Re: pg_connect takes 3.0 seconds
- Re: pg_connect takes 3.0 seconds
- Re: pg_connect takes 3.0 seconds
- Re: pg_connect takes 3.0 seconds
- Re: pg_connect takes 3.0 seconds
- Re: pg_connect takes 3.0 seconds
- Re: query looping?
- Re: DB is slow until DB is reloaded
- Re: DB is slow until DB is reloaded
- Re: pg_connect takes 3.0 seconds
- Re: query looping?
- Re: query looping?
- Re: forced sequential scan when condition has current_user
- Re: query looping?
- Re: pg_connect takes 3.0 seconds
- Re: forced sequential scan when condition has current_user
- Re: DB is slow until DB is reloaded
- Re: forced sequential scan when condition has current_user
- Re: pg_connect takes 3.0 seconds
- Re: DB is slow until DB is reloaded
- Re: pg_connect takes 3.0 seconds
- Re: forced sequential scan when condition has current_user
- pg_connect takes 3.0 seconds
- Re: forced sequential scan when condition has current_user
- Re: DB is slow until DB is reloaded
- Re: DB is slow until DB is reloaded
- Re: DB is slow until DB is reloaded
- Re: forced sequential scan when condition has current_user
- Re: DB is slow until DB is reloaded
- Re: forced sequential scan when condition has current_user
- Re: query looping?
- Re: DB is slow until DB is reloaded
- Re: DB is slow until DB is reloaded
- Re: forced sequential scan when condition has current_user
- Re: DB is slow until DB is reloaded
- Re: DB is slow until DB is reloaded
- Re: DB is slow until DB is reloaded
- Re: query looping?
- forced sequential scan when condition has current_user
- Re: DB is slow until DB is reloaded
- Re: DB is slow until DB is reloaded
- Re: DB is slow until DB is reloaded
- Re: DB is slow until DB is reloaded
- Re: DB is slow until DB is reloaded
- Re: DB is slow until DB is reloaded
- Re: DB is slow until DB is reloaded
- Re: DB is slow until DB is reloaded
- Re: DB is slow until DB is reloaded
- query looping?
- Re: DB is slow until DB is reloaded
- Re: DB is slow until DB is reloaded
- DB is slow until DB is reloaded
- Re: Message queue table - strange performance drop with changing limit size.
- Re: Message queue table - strange performance drop with changing limit size.
- Re: Message queue table - strange performance drop with changing limit size.
- Re: Message queue table - strange performance drop with changing limit size.
- Message queue table - strange performance drop with changing limit size.
- Re: Performance with partitions/inheritance and multiple tables
- Re:
- Re: [HACKERS] Faster CREATE DATABASE by delaying fsync (was 8.4.1 ubuntu karmic slow createdb)
- Re: [HACKERS] Faster CREATE DATABASE by delaying fsync (was 8.4.1 ubuntu karmic slow createdb)
- Re: [HACKERS] Faster CREATE DATABASE by delaying fsync (was 8.4.1 ubuntu karmic slow createdb)
- Re: [HACKERS] Faster CREATE DATABASE by delaying fsync (was 8.4.1 ubuntu karmic slow createdb)
- Re: [HACKERS] Faster CREATE DATABASE by delaying fsync (was 8.4.1 ubuntu karmic slow createdb)
- Re: [HACKERS] Faster CREATE DATABASE by delaying fsync (was 8.4.1 ubuntu karmic slow createdb)
- Re: [HACKERS] Faster CREATE DATABASE by delaying fsync (was 8.4.1 ubuntu karmic slow createdb)
- Re: [HACKERS] Faster CREATE DATABASE by delaying fsync (was 8.4.1 ubuntu karmic slow createdb)
- Re: [HACKERS] Faster CREATE DATABASE by delaying fsync (was 8.4.1 ubuntu karmic slow createdb)
- Re: Re: Faster CREATE DATABASE by delaying fsync (was 8.4.1 ubuntu karmic slow createdb)
- Re: Re: Faster CREATE DATABASE by delaying fsync (was 8.4.1 ubuntu karmic slow createdb)
- Re: Re: Faster CREATE DATABASE by delaying fsync (was 8.4.1 ubuntu karmic slow createdb)
- Re: [HACKERS] Re: Faster CREATE DATABASE by delaying fsync (was 8.4.1 ubuntu karmic slow createdb)
- Re: Faster CREATE DATABASE by delaying fsync (was 8.4.1 ubuntu karmic slow createdb)
- Re: 8.4.1 ubuntu karmic slow createdb
- Re: [HACKERS] Faster CREATE DATABASE by delaying fsync (was 8.4.1 ubuntu karmic slow createdb)
- Re: [HACKERS] Faster CREATE DATABASE by delaying fsync (was 8.4.1 ubuntu karmic slow createdb)
- Re: [HACKERS] Faster CREATE DATABASE by delaying fsync (was 8.4.1 ubuntu karmic slow createdb)
- Re: [HACKERS] Faster CREATE DATABASE by delaying fsync (was 8.4.1 ubuntu karmic slow createdb)
- Faster CREATE DATABASE by delaying fsync (was 8.4.1 ubuntu karmic slow createdb)
- Re: SATA drives performance
- Re: Order by (for 15 rows) adds 30 seconds to query time
- Re: Order by (for 15 rows) adds 30 seconds to query time
- Re: Order by (for 15 rows) adds 30 seconds to query time
- Re: SATA drives performance
- Re: Order by (for 15 rows) adds 30 seconds to query time
- Re: SATA drives performance
- Re: SATA drives performance
- Re: SATA drives performance
- Re: SATA drives performance
- Re: SATA drives performance
- From: Adam Tauno Williams
- Re: SATA drives performance
- Re: SATA drives performance
- Re: SATA drives performance
- Re: SATA drives performance
- Re: SATA drives performance
- Re: SATA drives performance
- Re: SATA drives performance
- Re: SATA drives performance
- Re: SATA drives performance
- Re: Multicolumn index - WHERE ... ORDER BY
- Re: SATA drives performance
- Re: Performance with partitions/inheritance and multiple tables
- Re: Optimizer use of index slows down query by factor
- Re: SATA drives performance
- Re: SATA drives performance
- Performance with partitions/inheritance and multiple tables
- SATA drives performance
- Multicolumn index - WHERE ... ORDER BY
- Optimizer use of index slows down query by factor
- Re: FSM - per database or per installation?
- Re: FSM - per database or per installation?
- Re: FSM - per database or per installation?
- Re: FSM - per database or per installation?
- Re: hardware priority for an SSD database?
- hardware priority for an SSD database?
- Re: Idea how to get rid of Bitmap Heap Scan
- Re: Idea how to get rid of Bitmap Heap Scan
- Re: Idea how to get rid of Bitmap Heap Scan
- Re: Idea how to get rid of Bitmap Heap Scan
- Re: Automatic optimization of IN clauses via INNER JOIN
- Re: Automatic optimization of IN clauses via INNER JOIN
- Re: Issues with \copy from file
- Re: Automatic optimization of IN clauses via INNER JOIN
- Re: Idea how to get rid of Bitmap Heap Scan
- Re: Idea how to get rid of Bitmap Heap Scan
- From: Michael N. Mikhulya
- Re: Issues with \copy from file
- From: Sigurgeir Gunnarsson
- Re: Idea how to get rid of Bitmap Heap Scan
- Idea how to get rid of Bitmap Heap Scan
- From: Michael N. Mikhulya
- Re: Automatic optimization of IN clauses via INNER JOIN
- From: Grzegorz Jaśkiewicz
- Re: Automatic optimization of IN clauses via INNER JOIN
- Re: Issues with \copy from file
- Re: Automatic optimization of IN clauses via INNER JOIN
- From: Grzegorz Jaśkiewicz
- Re: Automatic optimization of IN clauses via INNER JOIN
- Re: Issues with \copy from file
- From: Sigurgeir Gunnarsson
- Re: seq scan instead of index scan
- Re: Automatic optimization of IN clauses via INNER JOIN
- Re: seq scan instead of index scan
- Re: seq scan instead of index scan
- Re: seq scan instead of index scan
- Re: seq scan instead of index scan
- Re: seq scan instead of index scan
- Re: seq scan instead of index scan
- Re: seq scan instead of index scan
- Re: seq scan instead of index scan
- Re: seq scan instead of index scan
- seq scan instead of index scan
- Re: Automatic optimization of IN clauses via INNER JOIN
- From: Grzegorz Jaśkiewicz
- Re: Automatic optimization of IN clauses via INNER JOIN
- Re: Automatic optimization of IN clauses via INNER JOIN
- Re: Automatic optimization of IN clauses via INNER JOIN
- Re: Automatic optimization of IN clauses via INNER JOIN
- Automatic optimization of IN clauses via INNER JOIN
- Re: Parallel Function calls using multiple processes
- Re: Parallel Function calls using multiple processes
- Re: Parallel Function calls using multiple processes
- Parallel Function calls using multiple processes
- Re: big select is resulting in a large amount of disk writing by kjournald
- Re: 8.4.1 ubuntu karmic slow createdb
- Re: 8.4.1 ubuntu karmic slow createdb
- Re: 8.4.1 ubuntu karmic slow createdb
- Re: 8.4.1 ubuntu karmic slow createdb
- Re: 8.4.1 ubuntu karmic slow createdb
- Re: 8.4.1 ubuntu karmic slow createdb
- Re: 8.4.1 ubuntu karmic slow createdb
- Re: 8.4.1 ubuntu karmic slow createdb
- Re: 8.4.1 ubuntu karmic slow createdb
- Re: 8.4.1 ubuntu karmic slow createdb
- Re: 8.4.1 ubuntu karmic slow createdb
- Re: 8.4.1 ubuntu karmic slow createdb
- Re: 8.4.1 ubuntu karmic slow createdb
- Re: 8.4.1 ubuntu karmic slow createdb
- Re: 8.4.1 ubuntu karmic slow createdb
- Re: 8.4.1 ubuntu karmic slow createdb
- Re: Load experimentation
- Re: 8.4.1 ubuntu karmic slow createdb
- Re: Load experimentation
- Re: 8.4.1 ubuntu karmic slow createdb
- Re: 8.4.1 ubuntu karmic slow createdb
- Re: 8.4.1 ubuntu karmic slow createdb
- 8.4.1 ubuntu karmic slow createdb
- Re: Load experimentation
- Re: Fw: Help me put 2 Gigs of RAM to use
- Re: Fw: Help me put 2 Gigs of RAM to use
- Re: Help me put 2 Gigs of RAM to use
- Re: big select is resulting in a large amount of disk writing by kjournald
- Re: Fw: Help me put 2 Gigs of RAM to use
- Fw: Help me put 2 Gigs of RAM to use
- Re: big select is resulting in a large amount of disk writing by kjournald
- Re: big select is resulting in a large amount of disk writing by kjournald
- Re: big select is resulting in a large amount of disk writing by kjournald
- Re: big select is resulting in a large amount of disk writing by kjournald
- Re: big select is resulting in a large amount of disk writing by kjournald
- big select is resulting in a large amount of disk writing by kjournald
- Re: Load experimentation
- Re: Checkpoint spikes
- Re: Checkpoint spikes
- Re: Optimizing Bitmap Heap Scan.
- Re: performance penalty between Postgresql 8.3.8 and 8.4.1
- Re: Optimizing Bitmap Heap Scan.
- Re: Vacuum running out of memory
- Re: Vacuum running out of memory
- Re: Vacuum running out of memory
- Re: Vacuum running out of memory
- Re: performance penalty between Postgresql 8.3.8 and 8.4.1
- Re: performance penalty between Postgresql 8.3.8 and 8.4.1
- Re: error occured in dbt2 against with postgresql
- Re: Optimizing Bitmap Heap Scan.
- Vacuum running out of memory
- Re: performance penalty between Postgresql 8.3.8 and 8.4.1
- Re: Checkpoint spikes
- Re: performance penalty between Postgresql 8.3.8 and 8.4.1
- Re: Optimizing Bitmap Heap Scan.
- Re: Optimizing Bitmap Heap Scan.
- Re: SSD + RAID
- Re: Optimizing Bitmap Heap Scan.
- Re: Optimizing Bitmap Heap Scan.
- Re: Optimizing Bitmap Heap Scan.
- From: Grzegorz Jaśkiewicz
- Optimizing Bitmap Heap Scan.
- Re: performance penalty between Postgresql 8.3.8 and 8.4.1
- Re: performance penalty between Postgresql 8.3.8 and 8.4.1
- Re: performance penalty between Postgresql 8.3.8 and 8.4.1
- Re: performance penalty between Postgresql 8.3.8 and 8.4.1
- Re: performance penalty between Postgresql 8.3.8 and 8.4.1
- Re: performance penalty between Postgresql 8.3.8 and 8.4.1
- Re: Checkpoint spikes
- Re: Checkpoint spikes
- Re: performance penalty between Postgresql 8.3.8 and 8.4.1
- Re: performance penalty between Postgresql 8.3.8 and 8.4.1
- Re: Load experimentation
- Re: Load experimentation
- Re: Load experimentation
- Re: Load experimentation
- Re: Load experimentation
- Re: Load experimentation
- Re: Load experimentation
- Re: Dynamlically updating the estimated cost of a transaction
- error occured in dbt2 against with postgresql
- Re: performance penalty between Postgresql 8.3.8 and 8.4.1
- Dynamlically updating the estimated cost of a transaction
- Re: performance penalty between Postgresql 8.3.8 and 8.4.1
- Re: performance penalty between Postgresql 8.3.8 and 8.4.1
- Re: RAID card recommendation
- Re: RAID card recommendation
- Re: RAID card recommendation
- Re: RAID card recommendation
- Re: RAID card recommendation
- Re: performance penalty between Postgresql 8.3.8 and 8.4.1
- performance penalty between Postgresql 8.3.8 and 8.4.1
- Re: RAID card recommendation
- Re: Load experimentation
- Re: RAID card recommendation
- Re: Load experimentation
- Re: Load experimentation
- Re: Load experimentation
- Re: RAID card recommendation
- Re: RAID card recommendation
- Re: Load experimentation
- Re: Load experimentation
- Re: Load experimentation
- Re: Load experimentation
- Re: Load experimentation
- Load experimentation
- Re: Large DB, several tuning questions: Index sizes, VACUUM, REINDEX, Autovacuum
- Re: Large DB, several tuning questions: Index sizes, VACUUM, REINDEX, Autovacuum
- Re: Large DB, several tuning questions: Index sizes, VACUUM, REINDEX, Autovacuum
- Re: performance while importing a very large data set in to database
- Re: performance while importing a very large data set in to database
- Re: performance while importing a very large data set in to database
- From: Pierre Frédéric Caillaud
- Re: Large DB, several tuning questions: Index sizes, VACUUM, REINDEX, Autovacuum
- Re: Large DB, several tuning questions: Index sizes, VACUUM, REINDEX, Autovacuum
- Re: performance while importing a very large data set in to database
- Re: query cost too high, anyway to reduce it
- Re: performance while importing a very large data set in to database
- Re: Large DB, several tuning questions: Index sizes, VACUUM, REINDEX, Autovacuum
- Re: performance while importing a very large data set in to database
- From: "Ing . Marcos Luís Ortíz Valmaseda"
- Re: Large DB, several tuning questions: Index sizes, VACUUM, REINDEX, Autovacuum
- Re: performance while importing a very large data set in to database
- performance while importing a very large data set in to database
- Large DB, several tuning questions: Index sizes, VACUUM, REINDEX, Autovacuum
- query cost too high, anyway to reduce it
- Re: OpenMP in PostgreSQL-8.4.0
- Time Profiling inside the procedure
- Re: Server Freezing
- Re: SSD + RAID
- Re: Checkpoint spikes
- Re: Checkpoint spikes
- Re: Analyse without locking?
- Re: [BUGS] BUG #5228: Execution of prepared query is slow when timestamp parameter is used
- Re: Checkpoint spikes
- Re: Analyse without locking?
- Re: Query times change by orders of magnitude as DB ages
- Re: Order by (for 15 rows) adds 30 seconds to query time
- Re: Order by (for 15 rows) adds 30 seconds to query time
- Re: Order by (for 15 rows) adds 30 seconds to query time
- Re: Order by (for 15 rows) adds 30 seconds to query time
- Re: Order by (for 15 rows) adds 30 seconds to query time
- Re: Order by (for 15 rows) adds 30 seconds to query time
- Re: Order by (for 15 rows) adds 30 seconds to query time
- Re: Order by (for 15 rows) adds 30 seconds to query time
- Re: Cost of sort/order by not estimated by the query planner
- Re: Cost of sort/order by not estimated by the query planner
- Re: Cost of sort/order by not estimated by the query planner
- Re: Order by (for 15 rows) adds 30 seconds to query time
- Re: Cost of sort/order by not estimated by the query planner
- Re: Cost of sort/order by not estimated by the query planner
- Re: Cost of sort/order by not estimated by the query planner
- Re: Cost of sort/order by not estimated by the query planner
- Re: Cost of sort/order by not estimated by the query planner
- Re: Cost of sort/order by not estimated by the query planner
- Re: Cost of sort/order by not estimated by the query planner
- Re: Order by (for 15 rows) adds 30 seconds to query time
- Re: Order by (for 15 rows) adds 30 seconds to query time
- Re: RAID card recommendation
- Re: RAID card recommendation
- Re: RAID card recommendation
- Re: Order by (for 15 rows) adds 30 seconds to query time
- Re: Order by (for 15 rows) adds 30 seconds to query time
- Re: Order by (for 15 rows) adds 30 seconds to query time
- Re: Order by (for 15 rows) adds 30 seconds to query time
- Order by (for 15 rows) adds 30 seconds to query time
- Re: Server Freezing
- Re: Server Freezing
- Re: Server Freezing
- Re: Server Freezing
- Re: Server Freezing
- Re: Server Freezing
- Re: truncate in transaction blocks read access
- truncate in transaction blocks read access
- Server Freezing
- Re: SSD + RAID
- Re: SSD + RAID
- Re: SSD + RAID
- Re: query optimization
- Re: Any have tested ZFS like PostgreSQL installation filesystem?
- Re: Any have tested ZFS like PostgreSQL installation filesystem?
- From: "Ing . Marcos Luís Ortíz Valmaseda"
- Re: SSD + RAID
- Re: Any have tested ZFS like PostgreSQL installation filesystem?
- Re: SSD + RAID
- Any have tested ZFS like PostgreSQL installation filesystem?
- From: "Ing . Marcos Luís Ortíz Valmaseda"
- Re: SSD + RAID
- Re: SSD + RAID
- Re: OpenMP in PostgreSQL-8.4.0
- Re: OpenMP in PostgreSQL-8.4.0
- Re: OpenMP in PostgreSQL-8.4.0
- Re: OpenMP in PostgreSQL-8.4.0
- Re: Analyse without locking?
- Re: Analyse without locking?
- Re: OpenMP in PostgreSQL-8.4.0
- Re: Analyse without locking?
- Re: Analyse without locking?
- Re: OpenMP in PostgreSQL-8.4.0
- Re: SSD + RAID
- OpenMP in PostgreSQL-8.4.0
- Re: query optimization
- Re: Analyse without locking?
- Re: RAID card recommendation
- Re: Analyse without locking?
- Re: Analyse without locking?
- Re: Analyse without locking?
- From: Grzegorz Jaśkiewicz
- Analyse without locking?
- Re: Query times change by orders of magnitude as DB ages
- Re: Query times change by orders of magnitude as DB ages
- Re: Query times change by orders of magnitude as DB ages
- Re: Query times change by orders of magnitude as DB ages
- Re: query optimization
- Re: query optimization
- Re: Query times change by orders of magnitude as DB ages
- Re: query optimization
- Re: Query times change by orders of magnitude as DB ages
- From: Grzegorz Jaśkiewicz
- Re: Query times change by orders of magnitude as DB ages
- Re: RAID card recommendation
- Re: Query times change by orders of magnitude as DB ages
- From: Grzegorz Jaśkiewicz
- Re: Query times change by orders of magnitude as DB ages
- Re: DELETE performance problem
- From: Grzegorz Jaśkiewicz
- Re: DELETE performance problem
- Re: DELETE performance problem
- Re: How exactly does Analyze work?
- Re: How exactly does Analyze work?
- Re: Best possible way to insert and get returned ids
- How exactly does Analyze work?
- Re: Query times change by orders of magnitude as DB ages
- Re: Query times change by orders of magnitude as DB ages
- Re: Query times change by orders of magnitude as DB ages
- Re: Query times change by orders of magnitude as DB ages
- Re: Query times change by orders of magnitude as DB ages
- Re: RAID card recommendation
- Re: Strange performance degradation
- Re: RAID card recommendation
- Re: RAID card recommendation
- Re: RAID card recommendation
- Re: RAID card recommendation
- Re: DELETE performance problem
- Re: RAID card recommendation
- Re: RAID card recommendation
- Re: RAID card recommendation
- Re: RAID card recommendation
- Re: RAID card recommendation
- Re: RAID card recommendation
- Re: RAID card recommendation
- Re: RAID card recommendation
- From: Ing. Marcos Ortiz Valmaseda
- Re: [GENERAL] Strange performance degradation
- From: Ing. Marcos Ortiz Valmaseda
- Re: RAID card recommendation
- Re: RAID card recommendation
- Re: RAID card recommendation
- Re: RAID card recommendation
- Re: RAID card recommendation
- Re: RAID card recommendation
- RAID card recommendation
- Re: DELETE performance problem
- Re: Strange performance degradation
- Re: DELETE performance problem
- From: Grzegorz Jaśkiewicz
- Re: [GENERAL] Strange performance degradation
- Re: DELETE performance problem
- Re: DELETE performance problem
- Re: DELETE performance problem
- DELETE performance problem
- Re: Dynamic sql example
- Dynamic sql example
- Re: [GENERAL] Strange performance degradation
- Re: Query is slow when executing in procedure
- Re: Query is slow when executing in procedure
- Re: Query is slow when executing in procedure
- Re: Query is slow when executing in procedure
- Query is slow when executing in procedure
- Re: query optimization
- Re: query optimization
- From: Sebastian Jörgensen
- Re: query optimization
- Re: query optimization
- Re: query optimization
- query optimization
- Re: Best possible way to insert and get returned ids
- Re: [GENERAL] Strange performance degradation
- Best possible way to insert and get returned ids
- Re: [GENERAL] Strange performance degradation
- Re: Performance degrade running on multicore computer
- Re: Query times change by orders of magnitude as DB ages
- Re: View based upon function won't use index on joins
- Re: Why is the query not using the index for sorting?
- Re: Query times change by orders of magnitude as DB ages
- Re: Why is the query not using the index for sorting?
- Re: Query times change by orders of magnitude as DB ages
- Query times change by orders of magnitude as DB ages
- Re: Postgres query completion status?
- Re: Postgres query completion status?
- Re: Postgres query completion status?
- Re: Why is the query not using the index for sorting?
- Re: Why is the query not using the index for sorting?
- Re: Why is the query not using the index for sorting?
- Why is the query not using the index for sorting?
[Index of Archives]
[Postgresql General]
[Postgresql PHP]
[PHP Home]
[PHP on Windows]
[Yosemite]