Postgres Performance Date Index
[Prev Page][Next Page]
- Estimation issue with partitioned tables
- Re: How to troubleshoot high mem usage by postgres?
- Re: SSD + RAID
- Re: SSD + RAID
- Re: How to troubleshoot high mem usage by postgres?
- Re: How to troubleshoot high mem usage by postgres?
- Re: How to troubleshoot high mem usage by postgres?
- Re: How to troubleshoot high mem usage by postgres?
- Re: How to troubleshoot high mem usage by postgres?
- How to troubleshoot high mem usage by postgres?
- Re: SSD + RAID
- Re: SSD + RAID
- Re: SSD + RAID
- Re: bgwriter, checkpoints, curious (seeing delays)
- Re: bgwriter, checkpoints, curious (seeing delays)
- Re: bgwriter, checkpoints, curious (seeing delays)
- Re: bgwriter, checkpoints, curious (seeing delays)
- Re: bgwriter, checkpoints, curious (seeing delays)
- Re: bgwriter, checkpoints, curious (seeing delays)
- Re: bgwriter, checkpoints, curious (seeing delays)
- Re: Multiple data base on same server
- From: Ing. Marcos Ortiz Valmaseda
- Re: Multiple data base on same server
- Re: Multiple data base on same server
- Re: Multiple data base on same server
- Re: bgwriter, checkpoints, curious (seeing delays)
- Re: Multiple data base on same server
- Re: Multiple data base on same server
- Multiple data base on same server
- Re: bgwriter, checkpoints, curious (seeing delays)
- Re: bgwriter, checkpoints, curious (seeing delays)
- Re: bgwriter, checkpoints, curious (seeing delays)
- Re: bgwriter, checkpoints, curious (seeing delays)
- Re: bgwriter, checkpoints, curious (seeing delays)
- Re: bgwriter, checkpoints, curious (seeing delays)
- Re: bgwriter, checkpoints, curious (seeing delays)
- bgwriter, checkpoints, curious (seeing delays)
- Re: No hash join across partitioned tables?
- Re: No hash join across partitioned tables?
- Re: GiST index performance
- Re: GiST index performance
- Re: dbt2 performance
- Re: dbt2 performance
- dbt2 performance
- Re: Extracting superlatives - SQL design philosophy
- Re: Extracting superlatives - SQL design philosophy
- Re: Extracting superlatives - SQL design philosophy
- Re: Extracting superlatives - SQL design philosophy
- Re: Extracting superlatives - SQL design philosophy
- Re: Extracting superlatives - SQL design philosophy
- Re: Extracting superlatives - SQL design philosophy
- Re: Extracting superlatives - SQL design philosophy
- Re: Extracting superlatives - SQL design philosophy
- Re: Extracting superlatives - SQL design philosophy
- Re: Extracting superlatives - SQL design philosophy
- Re: Extracting superlatives - SQL design philosophy
- Extracting superlatives - SQL design philosophy
- Re: partitioned tables query not using indexes
- Re: partitioned tables query not using indexes
- Re: Internal operations when the planner makes a hash join.
- partitioned tables query not using indexes
- Re: SSD + RAID
- Re: Planner question - "bit" data types
- Thx and additional Q's .....
- Re: Internal operations when the planner makes a hash join.
- Re: Internal operations when the planner makes a hash join.
- Re: moving pg_xlog -- yeah, it's worth it!
- Re: Internal operations when the planner makes a hash join.
- Re: Internal operations when the planner makes a hash join.
- Re: SSD + RAID
- Re: moving pg_xlog -- yeah, it's worth it!
- Re: SSD + RAID
- Re: SSD + RAID
- Re: SSD + RAID
- Re: Internal operations when the planner makes a hash join.
- Re: SSD + RAID
- Re: Internal operations when the planner makes a hash join.
- Re: Internal operations when the planner makes a hash join.
- Re: Internal operations when the planner makes a hash join.
- Internal operations when the planner makes a hash join.
- Internal operations when the planner makes a hash join.
- Re: Slow query: table iteration (8.3)
- Re: SSD + RAID
- Re: SSD + RAID
- Re: SSD + RAID
- Re: Advice requested on structuring aggregation queries
- Advice requested on structuring aggregation queries
- Re: Planner question - "bit" data types
- Re: SSD + RAID
- Re: SSD + RAID
- Re: SSD + RAID
- Re: SSD + RAID
- Re: SSD + RAID
- Re: SSD + RAID
- Re: plpgsql plan cache
- Re: plpgsql plan cache
- Re: plpgsql plan cache
- Re: plpgsql plan cache
- Re: plpgsql plan cache
- Re: plpgsql plan cache
- plpgsql plan cache
- Re: SSD + RAID
- Re: shared_buffers
- shared_buffers
- Re: SSD + RAID
- Re: SSD + RAID
- Re: AutoVacuum_NapTime
- Re: SSD + RAID
- From: Arjen van der Meijden
- Re: SSD + RAID
- Re: Auto Vacuum out of memory
- Re: SSD + RAID
- Re: SSD + RAID
- Re: SSD + RAID
- Re: can we optimize STACK_DEPTH_SLOP
- Re: can we optimize STACK_DEPTH_SLOP
- can we optimize STACK_DEPTH_SLOP
- can we optimize STACK_DEPTH_SLOP
- Re: AutoVacuum_NapTime
- Re: AutoVacuum_NapTime
- AutoVacuum_NapTime
- Re: SSD + RAID
- Re: SSD + RAID
- Re: SSD + RAID
- Re: bgwriter tunables vs pg_stat_bgwriter
- Re: index usage in not like
- Re: index usage in not like
- Re: index usage in not like
- Re: index usage in not like
- Re: index usage in not like
- Re: index usage in not like
- index usage in not like
- Michael Clemmons wants to stay in touch on LinkedIn
- Re: bgwriter tunables vs pg_stat_bgwriter
- Re: bgwriter tunables vs pg_stat_bgwriter
- Re: disk space usage unexpected
- Re: disk space usage unexpected
- bgwriter tunables vs pg_stat_bgwriter
- Re: Dell PERC H700/H800
- From: Stefan Kaltenbrunner
- Re: 8.1 -> 8.4 regression
- Re: another 8.1->8.4 regression
- Re: Linux I/O tuning: CFQ vs. deadline
- another 8.1->8.4 regression
- Re: Almost infinite query -> Different Query Plan when changing where clause value
- Re: Almost infinite query -> Different Query Plan when changing where clause value
- Re: Why index is not using here?
- Re: Dell PERC H700/H800
- Re: Almost infinite query -> Different Query Plan when changing where clause value
- Re: Why index is not using here?
- Why index is not using here?
- Re: Almost infinite query -> Different Query Plan when changing where clause value
- Re: Almost infinite query -> Different Query Plan when changing where clause value
- Re: disk space usage unexpected
- Re: disk space usage unexpected
- Re: disk space usage unexpected
- Auto Vacuum out of memory
- disk space usage unexpected
- Re: 8.1 -> 8.4 regression
- Re: 8.1 -> 8.4 regression
- Re: Almost infinite query -> Different Query Plan when changing where clause value
- Re: 512,600ms query becomes 7500ms... but why? Postgres 8.3 query planner quirk?
- Re: 8.1 -> 8.4 regression
- Re: 8.1 -> 8.4 regression
- Re: Why primary key index are not using in joining?
- Re: PostgreSQL on SMP Architectures
- Re: Almost infinite query -> Different Query Plan when changing where clause value
- Re: Why primary key index are not using in joining?
- Re: 8.1 -> 8.4 regression
- Re: Almost infinite query -> Different Query Plan when changing where clause value
- Re: Why primary key index are not using in joining?
- Why primary key index are not using in joining?
- Re: PostgreSQL on SMP Architectures
- Re: PostgreSQL on SMP Architectures
- 8.1 -> 8.4 regression
- Re: PostgreSQL on SMP Architectures
- Re: PostgreSQL on SMP Architectures
- From: Arjen van der Meijden
- PostgreSQL on SMP Architectures
- Re: Deferred constraint and delete performance
- Re: 512,600ms query becomes 7500ms... but why? Postgres 8.3 query planner quirk?
- From: Pierre Frédéric Caillaud
- Re: Dell PERC H700/H800
- Re: Re: 512,600ms query becomes 7500ms... but why? Postgres 8.3 query planner quirk?
- Re: 512,600ms query becomes 7500ms... but why? Postgres 8.3 query planner quirk?
- Re: Re: 512,600ms query becomes 7500ms... but why? Postgres 8.3 query planner quirk?
- Re: 512,600ms query becomes 7500ms... but why? Postgres 8.3 query planner quirk?
- Re: Dell PERC H700/H800
- Re: moving pg_xlog -- yeah, it's worth it!
- Re: Almost infinite query -> Different Query Plan when changing where clause value
- Re: Almost infinite query -> Different Query Plan when changing where clause value
- Re: moving pg_xlog -- yeah, it's worth it!
- Re: 512,600ms query becomes 7500ms... but why? Postgres 8.3 query planner quirk?
- Re: Dell PERC H700/H800
- Re: Questions on plan with INSERT/SELECT on partitioned table
- Re: 512,600ms query becomes 7500ms... but why? Postgres 8.3 query planner quirk?
- Re: 512,600ms query becomes 7500ms... but why? Postgres 8.3 query planner quirk?
- Questions on plan with INSERT/SELECT on partitioned table
- Re: 512,600ms query becomes 7500ms... but why? Postgres 8.3 query planner quirk?
- Re: 512,600ms query becomes 7500ms... but why? Postgres 8.3 query planner quirk?
- Re: 512,600ms query becomes 7500ms... but why? Postgres 8.3 query planner quirk?
- Re: Almost infinite query -> Different Query Plan when changing where clause value
- Re: moving pg_xlog -- yeah, it's worth it!
- Re: moving pg_xlog -- yeah, it's worth it!
- Re: moving pg_xlog -- yeah, it's worth it!
- Almost infinite query -> Different Query Plan when changing where clause value
- Re: Immutable table functions
- Re: moving pg_xlog -- yeah, it's worth it!
- Immutable table functions
- From: Luiz Angelo Daros de Luca
- Re: Dell PERC H700/H800
- Re: Dell PERC H700/H800
- Re: Dell PERC H700/H800
- Re: moving pg_xlog -- yeah, it's worth it!
- Re: moving pg_xlog -- yeah, it's worth it!
- Re: moving pg_xlog -- yeah, it's worth it!
- Re: moving pg_xlog -- yeah, it's worth it!
- Re: Dell PERC H700/H800
- Re: Dell PERC H700/H800
- Re: moving pg_xlog -- yeah, it's worth it!
- Re: perf problem with huge table
- Re: Re: 512,600ms query becomes 7500ms... but why? Postgres 8.3 query planner quirk?
- Dell PERC H700/H800
- Re: moving pg_xlog -- yeah, it's worth it!
- Re: perf problem with huge table
- Re: Re: 512,600ms query becomes 7500ms... but why? Postgres 8.3 query planner quirk?
- Re: How exactly PostgreSQL allocates memory for its needs?
- Re: [HACKERS] Re: Faster CREATE DATABASE by delaying fsync (was 8.4.1 ubuntu karmic slow createdb)
- Re: Linux I/O tuning: CFQ vs. deadline
- Re: Re: 512,600ms query becomes 7500ms... but why? Postgres 8.3 query planner quirk?
- Re: Linux I/O tuning: CFQ vs. deadline
- Re: Linux I/O tuning: CFQ vs. deadline
- Re: perf problem with huge table
- Re: perf problem with huge table
- Re: perf problem with huge table
- Re: perf problem with huge table
- Re: perf problem with huge table
- Re: Re: 512,600ms query becomes 7500ms... but why? Postgres 8.3 query planner quirk?
- Re: perf problem with huge table
- Re: perf problem with huge table
- perf problem with huge table
- Re: Re: 512,600ms query becomes 7500ms... but why? Postgres 8.3 query planner quirk?
- Re: Linux I/O tuning: CFQ vs. deadline
- Re: Deferred constraint and delete performance
- Re: Linux I/O tuning: CFQ vs. deadline
- Re: How exactly PostgreSQL allocates memory for its needs?
- Re: PostgreSQL - case studies
- Re: PostgreSQL - case studies
- Re: [GENERAL] PostgreSQL - case studies
- From: Ing. Marcos L. Ortiz Valmaseda
- Re: Deferred constraint and delete performance
- Deferred constraint and delete performance
- Re: Re: 512,600ms query becomes 7500ms... but why? Postgres 8.3 query planner quirk?
- Re: 512,600ms query becomes 7500ms... but why? Postgres 8.3 query planner quirk?
- Re: Linux I/O tuning: CFQ vs. deadline
- Re: Linux I/O tuning: CFQ vs. deadline
- Re: [GENERAL] PostgreSQL - case studies
- How exactly PostgreSQL allocates memory for its needs?
- Re: PostgreSQL - case studies
- 512,600ms query becomes 7500ms... but why? Postgres 8.3 query planner quirk?
- PostgreSQL - case studies
- Re: DISTINCT vs. GROUP BY
- Re: Linux I/O tuning: CFQ vs. deadline
- Re: DISTINCT vs. GROUP BY
- Re: DISTINCT vs. GROUP BY
- DISTINCT vs. GROUP BY
- Re: moving pg_xlog -- yeah, it's worth it!
- Re: moving pg_xlog -- yeah, it's worth it!
- Re: moving pg_xlog -- yeah, it's worth it!
- Re: moving pg_xlog -- yeah, it's worth it!
- moving pg_xlog -- yeah, it's worth it!
- Re: foreign key constraint lock behavour in postgresql
- Re: [GENERAL] index is not using
- Re: [GENERAL] index is not using
- Re: index is not using?
- index is not using?
- Re: Linux I/O tuning: CFQ vs. deadline
- Re: Linux I/O tuning: CFQ vs. deadline
- Re: Linux I/O tuning: CFQ vs. deadline
- Re: Linux I/O tuning: CFQ vs. deadline
- Re: Linux I/O tuning: CFQ vs. deadline
- Re: [HACKERS] Re: Faster CREATE DATABASE by delaying fsync (was 8.4.1 ubuntu karmic slow createdb)
- Re: Linux I/O tuning: CFQ vs. deadline
- Re: [HACKERS] Re: Faster CREATE DATABASE by delaying fsync (was 8.4.1 ubuntu karmic slow createdb)
- Re: Linux I/O tuning: CFQ vs. deadline
- Re: Linux I/O tuning: CFQ vs. deadline
- Re: Linux I/O tuning: CFQ vs. deadline
- Re: Linux I/O tuning: CFQ vs. deadline
- Linux I/O tuning: CFQ vs. deadline
- Re: foreign key constraint lock behavour in postgresql
- Re: [HACKERS] 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: [HACKERS] 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: [HACKERS] 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: [HACKERS] 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: [HACKERS] 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: Slow query: table iteration (8.3)
- Re: [HACKERS] Re: Faster CREATE DATABASE by delaying fsync (was 8.4.1 ubuntu karmic slow createdb)
- Re: Slow query: table iteration (8.3)
- Re: index on partitioned table
- Re: foreign key constraint lock behavour in postgresql
- Re: index on partitioned table
- index on partitioned table
- Re: Slow query: table iteration (8.3)
- Re: foreign key constraint lock behavour in postgresql
- Re: Slow query: table iteration (8.3)
- Re: foreign key constraint lock behavour in postgresql
- Re: Slow-ish Query Needs Some Love
- Re: Slow query: table iteration (8.3)
- Re: bigint integers up to 19 digits.
- Re: bigint integers up to 19 digits.
- Re: bigint integers up to 19 digits.
- Re: bigint integers up to 19 digits.
- Re: bigint integers up to 19 digits.
- bigint integers up to 19 digits.
- Re: Optimizing Postgresql server and FreeBSD for heavy read and writes
- Re: Air-traffic benchmark
- Re: Optimizing Postgresql server and FreeBSD for heavy read and writes
- Re: Optimizing Postgresql server and FreeBSD for heavy read and writes
- Re: Optimizing Postgresql server and FreeBSD for heavy read and writes
- Re: Optimizing Postgresql server and FreeBSD for heavy read and writes
- Re: Slow query: table iteration (8.3)
- Re: Optimizing Postgresql server and FreeBSD for heavy read and writes
- Re: Re: Optimizing Postgresql server and FreeBSD for heavy read and writes
- Re: Slow query: table iteration (8.3)
- From: Grzegorz Jaśkiewicz
- Re: Slow query: table iteration (8.3)
- Re: some problems when i use postgresql 8.4.2 in my projects .
- From: Pierre Frédéric Caillaud
- Re: Slow query: table iteration (8.3)
- Re: foreign key constraint lock behavour in postgresql
- Re: System overload / context switching / oom, 8.3
- foreign key constraint lock behavour in postgresql
- Re: Slow query: table iteration (8.3)
- Re: System overload / context switching / oom, 8.3
- Re: Optimizing Postgresql server and FreeBSD for heavy read and writes
- Re: Optimizing Postgresql server and FreeBSD for heavy read and writes
- Re: System overload / context switching / oom, 8.3
- Re: Queries within a function
- Re: Slow-ish Query Needs Some Love
- Re: Optimizing Postgresql server and FreeBSD for heavy read and writes
- Re: Optimizing Postgresql server and FreeBSD for heavy read and writes
- Re: Re: Optimizing Postgresql server and FreeBSD for heavy read and writes
- Re: Queries within a function
- Re: queries with subquery constraints on partitioned tables not optimized?
- Re: some problems when i use postgresql 8.4.2 in my projects .
- Re: Optimizing Postgresql server and FreeBSD for heavy read and writes
- Optimizing Postgresql server and FreeBSD for heavy read and writes
- Re: some problems when i use postgresql 8.4.2 in my projects .
- Re: [HACKERS] 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: [HACKERS] 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: System overload / context switching / oom, 8.3
- Re: queries with subquery constraints on partitioned tables not optimized?
- Re: the jokes for pg concurrency write performance
- Re: System overload / context switching / oom, 8.3
- Re: the jokes for pg concurrency write performance
- Re: Queries within a function
- some problems when i use postgresql 8.4.2 in my projects .
- Re: queries with subquery constraints on partitioned tables not optimized?
- Slow-ish Query Needs Some Love
- queries with subquery constraints on partitioned tables not optimized?
- Re: Slow-ish Query Needs Some Love
- Re: Slow-ish Query Needs Some Love
- Re: System overload / context switching / oom, 8.3
- Re: System overload / context switching / oom, 8.3
- Re: Queries within a function
- Re: System overload / context switching / oom, 8.3
- Re: Queries within a function
- Re: System overload / context switching / oom, 8.3
- Re: System overload / context switching / oom, 8.3
- Re: System overload / context switching / oom, 8.3
- Re: Slow-ish Query Needs Some Love
- Re: Re: 回复:Re: [PERFORM] the jokes for pg concurrency write performance
- Re: Queries within a function
- From: "Ing. Marcos Ortiz Valmaseda"
- Re: [HACKERS] 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: Queries within a function
- System overload / context switching / oom, 8.3
- Re: Queries within a function
- Re: [HACKERS] 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: use pgsql in a big project, but i found pg has some big problem on concurrency write operation, maybe a joke for myself !
- Re: [HACKERS] Re: Faster CREATE DATABASE by delaying fsync (was 8.4.1 ubuntu karmic slow createdb)
- Queries within a function
- Re: [HACKERS] Re: Faster CREATE DATABASE by delaying fsync (was 8.4.1 ubuntu karmic slow createdb)
- Re: the jokes for pg concurrency write performance
- Re: [HACKERS] 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: [HACKERS] Re: Faster CREATE DATABASE by delaying fsync (was 8.4.1 ubuntu karmic slow createdb)
- Re: 回复:Re: [PERFORM] the jokes for pg concurrency write performance
- Re: the jokes for pg concurrency write performance
- Re: the jokes for pg concurrency write performance
- Re: Slow query: table iteration (8.3)
- Sincere apology for my insults and hand-waving in these mails:the jokes for pg concurrency write performance
- Re: the jokes for pg concurrency write performance
- Re: the jokes for pg concurrency write performance
- Re: use pgsql in a big project, but i found pg has some big problem on concurrency write operation, maybe a joke for myself !
- the jokes for pg concurrency write performance
- use pgsql in a big project, but i found pg has some big problem on concurrency write operation, maybe a joke for myself !
- Re: Slow query: table iteration (8.3)
- Re: Slow query: table iteration (8.3)
- Re: Constraint propagating for equal fields
- Slow query: table iteration (8.3)
- Re: Constraint propagating for equal fields
- Re: Limited Shared Buffer Problem
- Re: Faster CREATE DATABASE by delaying fsync (was 8.4.1 ubuntu karmic slow createdb)
- Re: Limited Shared Buffer Problem
- Re: Limited Shared Buffer Problem
- Re: Limited Shared Buffer Problem
- From: jose javier parra sanchez
- Re: Limited Shared Buffer Problem
- From: "Ing . Marcos Luís Ortíz Valmaseda"
- Re: Limited Shared Buffer Problem
- Re: Limited Shared Buffer Problem
- Limited Shared Buffer Problem
- Constraint propagating for equal fields
- Re: Benchmark shows very slow bulk delete
- Re: Benchmark shows very slow bulk delete
- Re: Benchmark shows very slow bulk delete
- Re: Should the optimiser convert a CASE into a WHERE if it can?
- Re: Should the optimiser convert a CASE into a WHERE if it can?
- Re: Should the optimiser convert a CASE into a WHERE if it can?
- Re: Benchmark shows very slow bulk delete
- Re: test send (recommended by Dave Page)
- Re: Benchmark shows very slow bulk delete
- Re: test send (recommended by Dave Page)
- test send (recommended by Dave Page)
- Re: Benchmark shows very slow bulk delete
- Re: Benchmark shows very slow bulk delete
- Re: Benchmark shows very slow bulk delete
- Benchmark shows very slow bulk delete
- Re: [HACKERS] Re: Faster CREATE DATABASE by delaying fsync (was 8.4.1 ubuntu karmic slow createdb)
- Re: Inserting 8MB bytea: just 25% of disk perf used?
- Re: New server to improve performance on our large and busy DB - advice?
- Re: Should the optimiser convert a CASE into a WHERE if it can?
- Re: Inserting 8MB bytea: just 25% of disk perf used?
- Re: Poor query plan across OR operator
- Re: Poor query plan across OR operator
- Re: splitting data into multiple tables
- Re: Poor query plan across OR operator
- Re: splitting data into multiple tables
- Re: Should the optimiser convert a CASE into a WHERE if it can?
- Re: splitting data into multiple tables
- Re: Should the optimiser convert a CASE into a WHERE if it can?
- Re: Should the optimiser convert a CASE into a WHERE if it can?
- Should the optimiser convert a CASE into a WHERE if it can?
- Re: Poor query plan across OR operator
- Re: Poor query plan across OR operator
- From: Grzegorz Jaśkiewicz
- Poor query plan across OR operator
- Re: splitting data into multiple tables
- Re: splitting data into multiple tables
- Re: splitting data into multiple tables
- Re: splitting data into multiple tables
- Re: splitting data into multiple tables
- Re: splitting data into multiple tables
- Re: splitting data into multiple tables
- Re: Data Set Growth causing 26+hour runtime, on what we believe to be very simple SQL
- Re: splitting data into multiple tables
- Re: splitting data into multiple tables
- Re: splitting data into multiple tables
- Re: splitting data into multiple tables
- splitting data into multiple tables
- Re: Inserting 8MB bytea: just 25% of disk perf used?
- From: fkater@xxxxxxxxxxxxxx
- Re: Sql result b where condition
- Re: Sql result b where condition
- Re: Data Set Growth causing 26+hour runtime, on what we believe to be very simple SQL
- Re: Data Set Growth causing 26+hour runtime, on what we believe to be very simple SQL
- Re: Sql result b where condition
- Sql result b where condition
- Re: Fragmentation/Vacuum, Analyze, Re-Index
- Re: Inserting 8MB bytea: just 25% of disk perf used?
- Re: Inserting 8MB bytea: just 25% of disk perf used?
- Re: Inserting 8MB bytea: just 25% of disk perf used?
- Re: Data Set Growth causing 26+hour runtime, on what we believe to be very simple SQL
- Re: Inserting 8MB bytea: just 25% of disk perf used?
- From: fkater@xxxxxxxxxxxxxx
- Re: Fragmentation/Vacuum, Analyze, Re-Index
- Re: Data Set Growth causing 26+hour runtime, on what we believe to be very simple SQL
- Re: Data Set Growth causing 26+hour runtime, on what we believe to be very simple SQL
- Re: Data Set Growth causing 26+hour runtime, on what we believe to be very simple SQL
- Re: Data Set Growth causing 26+hour runtime, on what we believe to be very simple SQL
- Re: Data Set Growth causing 26+hour runtime, on what we believe to be very simple SQL
- Re: Data Set Growth causing 26+hour runtime, on what we believe to be very simple SQL
- Re: Data Set Growth causing 26+hour runtime, on what we believe to be very simple SQL
- Re: New server to improve performance on our large and busy DB - advice?
- Re: Fragmentation/Vacuum, Analyze, Re-Index
- Re: Slow update query
- Slow update query
- Re: Data Set Growth causing 26+hour runtime, on what we believe to be very simple SQL
- Fragmentation/Vacuum, Analyze, Re-Index
- Re: Data Set Growth causing 26+hour runtime, on what we believe to be very simple SQL
- Re: Slow update query
- Re: ext4 finally doing the right thing
- Re: TPC-C implementation for postgresql?
- TPC-C implementation for postgresql?
- Re: performance question on VACUUM FULL (Postgres 8.4.2)
- Data Set Growth causing 26+hour runtime, on what we believe to be very simple SQL
- Re: New server to improve performance on our large and busy DB - advice?
- Re: Slow update query
- Slow update query
- Re: New server to improve performance on our large and busy DB - advice?
- Re: New server to improve performance on our large and busy DB - advice?
- Re: New server to improve performance on our large and busy DB - advice?
- Re: ext4 finally doing the right thing
- From: Pierre Frédéric Caillaud
- Re: Inserting 8MB bytea: just 25% of disk perf used?
- Re: ext4 finally doing the right thing
- Re: New server to improve performance on our large and busy DB - advice?
- Re: Slow update query
- Slow update query
- Re: ext4 finally doing the right thing
- Re: ext4 finally doing the right thing
- Re: ext4 finally doing the right thing
- Re: ext4 finally doing the right thing
- Re: Inserting 8MB bytea: just 25% of disk perf used?
- Re: a heavy duty operation on an "unused" table kills my server
- Re: ext4 finally doing the right thing
- Re: Inserting 8MB bytea: just 25% of disk perf used?
- Re: Inserting 8MB bytea: just 25% of disk perf used?
- Re: ext4 finally doing the right thing
- Re: ext4 finally doing the right thing
- Re: New server to improve performance on our large and busy DB - advice?
- Re: Re: New server to improve performance on our large and busy DB - advice? (v2)
- Re: ext4 finally doing the right thing
- Re: New server to improve performance on our large and busy DB - advice?
- Re: a heavy duty operation on an "unused" table kills my server
- Re: New server to improve performance on our large and busy DB - advice?
- Re: Change query join order
- From: Kaloyan Iliev Iliev
- Re: a heavy duty operation on an "unused" table kills my server
- 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: Re: Faster CREATE DATABASE by delaying fsync (was 8.4.1 ubuntu karmic slow createdb)
- Re: renice on an I/O bound box
- Re: ext4 finally doing the right thing
- Re: New server to improve performance on our large and busy DB - advice?
- Re: performance question on VACUUM FULL (Postgres 8.4.2)
- Re: New server to improve performance on our large and busy DB - advice?
- Re: Inserting 8MB bytea: just 25% of disk perf used?
- performance question on VACUUM FULL (Postgres 8.4.2)
- Re: renice on an I/O bound box
- From: Arjen van der Meijden
- Re: renice on an I/O bound box
- Re: renice on an I/O bound box
- From: Ing. Marcos L. Ortiz Valmaseda
- Re: Inserting 8MB bytea: just 25% of disk perf used?
- Re: [HACKERS] Re: Faster CREATE DATABASE by delaying fsync (was 8.4.1 ubuntu karmic slow createdb)
- Re: Inserting 8MB bytea: just 25% of disk perf used?
- 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: Faster CREATE DATABASE by delaying fsync (was 8.4.1 ubuntu karmic slow createdb)
- Re: Inserting 8MB bytea: just 25% of disk perf used?
- From: fkater@xxxxxxxxxxxxxx
- renice on an I/O bound box
- Re: Inserting 8MB bytea: just 25% of disk perf used?
- Re: Inserting 8MB bytea: just 25% of disk perf used?
- Re: Inserting 8MB bytea: just 25% of disk perf used?
- From: fkater@xxxxxxxxxxxxxx
- Re: Inserting 8MB bytea: just 25% of disk perf used?
- From: fkater@xxxxxxxxxxxxxx
- Re: Inserting 8MB bytea: just 25% of disk perf used?
- From: fkater@xxxxxxxxxxxxxx
- Re: Inserting 8MB bytea: just 25% of disk perf used?
- Re: Bad plan choice nestloop vs. hashjoin
- Re: Bad plan choice nestloop vs. hashjoin
- Re: Inserting 8MB bytea: just 25% of disk perf used?
- From: fkater@xxxxxxxxxxxxxx
- Re: Faster CREATE DATABASE by delaying fsync (was 8.4.1 ubuntu karmic slow createdb)
- Re: Inserting 8MB bytea: just 25% of disk perf used?
- From: fkater@xxxxxxxxxxxxxx
- Re: Inserting 8MB bytea: just 25% of disk perf used?
- From: fkater@xxxxxxxxxxxxxx
- Re: Inserting 8MB bytea: just 25% of disk perf used?
- From: fkater@xxxxxxxxxxxxxx
- Re: Inserting 8MB bytea: just 25% of disk perf used?
- From: fkater@xxxxxxxxxxxxxx
- Re: Inserting 8MB bytea: just 25% of disk perf used?
- From: fkater@xxxxxxxxxxxxxx
- 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: Inserting 8MB bytea: just 25% of disk perf used?
- From: Pierre Frédéric Caillaud
- 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: a heavy duty operation on an "unused" table kills my server
- Re: a heavy duty operation on an "unused" table kills my server
- ext4 finally doing the right thing
- Re: a heavy duty operation on an "unused" table kills my server
- Re: New server to improve performance on our large and busy DB - advice? (v2)
- Re: New server to improve performance on our large and busy DB - advice? (v2)
- Re: New server to improve performance on our large and busy DB - advice? (v2)
- Re: New server to improve performance on our large and busy DB - advice? (v2)
- Re: a heavy duty operation on an "unused" table kills my server
- Re: Bad plan choice nestloop vs. hashjoin
- Re: Bad plan choice nestloop vs. hashjoin
- Re: Inserting 8MB bytea: just 25% of disk perf used?
- Re: Bad plan choice nestloop vs. hashjoin
- Bad plan choice nestloop vs. hashjoin
- Re: a heavy duty operation on an "unused" table kills my server
- Re: New server to improve performance on our large and busy DB - advice? (v2)
- Re: new server I/O setup
- Re: New server to improve performance on our large and busy DB - advice? (v2)
- Re: Inserting 8MB bytea: just 25% of disk perf used?
- Re: Inserting 8MB bytea: just 25% of disk perf used?
- From: fkater@xxxxxxxxxxxxxx
- Re: Inserting 8MB bytea: just 25% of disk perf used?
- From: fkater@xxxxxxxxxxxxxx
- Re: new server I/O setup
- Re: new server I/O setup
- Re: Re: New server to improve performance on our large and busy DB - advice? (v2)
- From: Ing. Marcos L. Ortiz Valmaseda
- Re: New server to improve performance on our large and busy DB - advice? (v2)
- Re: a heavy duty operation on an "unused" table kills my server
- Re: new server I/O setup
- From: Pierre Frédéric Caillaud
- Re: Re: New server to improve performance on our large and busy DB - advice? (v2)
- Re: a heavy duty operation on an "unused" table kills my server
- Re: OT: Db2 connection pooling?
- OT: Db2 connection pooling?
- Re: new server I/O setup
- Re: a heavy duty operation on an "unused" table kills my server
- Re: new server I/O setup
- Re: New server to improve performance on our large and busy DB - advice? (v2)
- Re: new server I/O setup
- Re: New server to improve performance on our large and busy DB - advice?
- Re: Re: New server to improve performance on our large and busy DB - advice? (v2)
- From: Pierre Frédéric Caillaud
- Re: New server to improve performance on our large and busy DB - advice? (v2)
- Re: New server to improve performance on our large and busy DB - advice? (v2)
- Re: New server to improve performance on our large and busy DB - advice? (v2)
- Re: New server to improve performance on our large and busy DB - advice? (v2)
- Re: Inserting 8MB bytea: just 25% of disk perf used?
- Re: new server I/O setup
- Re: Inserting 8MB bytea: just 25% of disk perf used?
- Re: a heavy duty operation on an "unused" table kills my server
- Re: Inserting 8MB bytea: just 25% of disk perf used?
- From: Pierre Frédéric Caillaud
- Re: Inserting 8MB bytea: just 25% of disk perf used?
- Re: New server to improve performance on our large and busy DB - advice?
- Re: new server I/O setup
- Re: Inserting 8MB bytea: just 25% of disk perf used?
- Re: New server to improve performance on our large and busy DB - advice?
- Re: New server to improve performance on our large and busy DB - advice? (v2)
- Re: Inserting 8MB bytea: just 25% of disk perf used?
- From: Pierre Frédéric Caillaud
- Re: New server to improve performance on our large and busy DB - advice? (v2)
- Re: Massive table (500M rows) update nightmare
- New server to improve performance on our large and busy DB - advice? (v2)
- Re: New server to improve performance on our large and busy DB - advice?
- Re: Massive table (500M rows) update nightmare
- Re: Inserting 8MB bytea: just 25% of disk perf used?
- Re: Inserting 8MB bytea: just 25% of disk perf used?
- From: fkater@xxxxxxxxxxxxxx
- Re: Inserting 8MB bytea: just 25% of disk perf used?
- From: fkater@xxxxxxxxxxxxxx
- Re: Inserting 8MB bytea: just 25% of disk perf used?
- From: fkater@xxxxxxxxxxxxxx
- Re: new server I/O setup
- 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: Inserting 8MB bytea: just 25% of disk perf used?
- From: fkater@xxxxxxxxxxxxxx
- Re: Inserting 8MB bytea: just 25% of disk perf used?
- From: fkater@xxxxxxxxxxxxxx
- Re: Inserting 8MB bytea: just 25% of disk perf used?
- From: fkater@xxxxxxxxxxxxxx
- new server I/O setup
- Re: New server to improve performance on our large and busy DB - advice?
- Re: Massive table (500M rows) update nightmare
- New server to improve performance on our large and busy DB - advice?
- Re: Slow "Select count(*) ..." query on table with 60 Mio. rows
- Re: Slow "Select count(*) ..." query on table with 60 Mio. rows
- Re: bad execution plan for subselects containing windowing-function
- Re: a heavy duty operation on an "unused" table kills my server
- Re: Slow "Select count(*) ..." query on table with 60 Mio. rows
- Re: a heavy duty operation on an "unused" table kills my server
- Re: Slow "Select count(*) ..." query on table with 60 Mio. rows
- Re: a heavy duty operation on an "unused" table kills my server
- Re: bad execution plan for subselects containing windowing-function
- Re: Slow "Select count(*) ..." query on table with 60 Mio. rows
- Re: bad execution plan for subselects containing windowing-function
- Re: bad execution plan for subselects containing windowing-function
- Re: bad execution plan for subselects containing windowing-function
- bad execution plan for subselects containing windowing-function
- Re: a heavy duty operation on an "unused" table kills my server
- From: Pierre Frédéric Caillaud
- Re: Inserting 8MB bytea: just 25% of disk perf used?
- From: Pierre Frédéric Caillaud
- Re: Slow "Select count(*) ..." query on table with 60 Mio. rows
- Re: Slow "Select count(*) ..." query on table with 60 Mio. rows
- Re: performance config help
- From: Pierre Frédéric Caillaud
- Re: Slow "Select count(*) ..." query on table with 60 Mio. rows
- Re: Slow "Select count(*) ..." query on table with 60 Mio. rows
- Re: Inserting 8MB bytea: just 25% of disk perf used?
- Re: Slow "Select count(*) ..." query on table with 60 Mio. rows
- Re: Inserting 8MB bytea: just 25% of disk perf used?
- Re: Inserting 8MB bytea: just 25% of disk perf used?
- Slow "Select count(*) ..." query on table with 60 Mio. rows
[Index of Archives]
[Postgresql General]
[Postgresql PHP]
[PHP Home]
[PHP on Windows]
[Yosemite]