Postgres Performance Date Index
[Prev Page][Next Page]
- Re: PostgreSQL seems to create inefficient plans in simple conditional joins
- Re: bad COPY performance with NOTIFY in a trigger
- From: Filip Rembiałkowski
- Re: bad COPY performance with NOTIFY in a trigger
- Re: View containing a recursive function
- Re: bad COPY performance with NOTIFY in a trigger
- From: Filip Rembiałkowski
- Re: gin performance issue.
- Re: bad COPY performance with NOTIFY in a trigger
- From: Filip Rembiałkowski
- gin performance issue.
- Re: bad COPY performance with NOTIFY in a trigger
- Re: bad COPY performance with NOTIFY in a trigger
- bad COPY performance with NOTIFY in a trigger
- From: Filip Rembiałkowski
- Re: Bitmap and-ing between btree and gin?
- Re: Bitmap and-ing between btree and gin?
- Bitmap and-ing between btree and gin?
- Understanding ANALYZE memory usage with "big" tsvector columns
- Re: Hash join gets slower as work_mem increases?
- Re: Hash join gets slower as work_mem increases?
- Re: View containing a recursive function
- Re: Hash join gets slower as work_mem increases?
- View containing a recursive function
- Re: PostgreSQL seems to create inefficient plans in simple conditional joins
- Re: PostgreSQL seems to create inefficient plans in simple conditional joins
- Re: PostgreSQL seems to create inefficient plans in simple conditional joins
- Re: PostgreSQL seems to create inefficient plans in simple conditional joins
- Re: PostgreSQL seems to create inefficient plans in simple conditional joins
- Re: Hash join gets slower as work_mem increases?
- PostgreSQL seems to create inefficient plans in simple conditional joins
- Re: jsonb_agg performance
- jsonb_agg performance
- Re: Hash join gets slower as work_mem increases?
- Hash join gets slower as work_mem increases?
- Re: Postgres partitions-query scanning all child tables
- Re: Postgres partitions-query scanning all child tables
- Re: Postgres partitions-query scanning all child tables
- Re: Postgres partitions-query scanning all child tables
- performance issue with inherited foreign table
- Postgres partitions-query scanning all child tables
- Re: Primary key index partially used
- Re: Primary key index partially used
- Primary key index partially used
- Re: insert performance
- Re: High Planning Time
- Re: High Planning Time
- Re: High Planning Time
- Re: insert performance
- High Planning Time
- Re: insert performance
- Re: Query order of magnitude slower with slightly different where clause
- Query order of magnitude slower with slightly different where clause
- Re: insert performance
- Re: insert performance
- Re: Queries getting canceled inside a proc that seems to slow down randomly
- Re: Queries getting canceled inside a proc that seems to slow down randomly
- Re: Queries getting canceled inside a proc that seems to slow down randomly
- Re: insert performance
- Re: insert performance
- insert performance
- Re: How we made Postgres upserts 2-3* quicker than MongoDB
- Re: How we made Postgres upserts 2-3* quicker than MongoDB
- Re: How we made Postgres upserts 2-3* quicker than MongoDB
- How we made Postgres upserts 2-3* quicker than MongoDB
- Re: Queries intermittently slow
- Re: Queries intermittently slow
- Re: Slow query help
- From: Almir de Oliveira Duarte Junior
- Re: Slow query help
- Re: Slow query help
- From: Rafael Bernard Rodrigues Araujo
- Re: Queries intermittently slow
- Re: Queries intermittently slow
- Re: Queries intermittently slow
- Re: Queries intermittently slow
- Re: Queries intermittently slow
- Re: Queries intermittently slow
- Slow query help
- From: Almir de Oliveira Duarte Junior
- Re: Queries intermittently slow
- Re: Queries intermittently slow
- Re: Materialized view performance problems
- Re: Queries intermittently slow
- Re: Queries intermittently slow
- Re: Queries intermittently slow
- Re: Queries intermittently slow
- Re: Queries intermittently slow
- Re: Queries intermittently slow
- Re: Queries intermittently slow
- Queries intermittently slow
- Re: Materialized view performance problems
- Re: Materialized view performance problems
- Materialized view performance problems
- Re: Proposal for unlogged tables
- Re: Proposal for unlogged tables
- Re: Proposal for unlogged tables
- Re: Proposal for unlogged tables
- Re: Proposal for unlogged tables
- Re: Plan differences
- Proposal for unlogged tables
- Re: Plan differences
- Re: Plan differences
- Re: Plan differences
- Re: Plan differences
- Re: Plan differences
- Re: Plan differences
- Re: Plan differences
- Re: Plan differences
- Plan differences
- Re: [ADMIN] Connections "Startup"
- Re: [ADMIN] Connections "Startup"
- Re: [ADMIN] Connections "Startup"
- Re: Connections "Startup"
- Re: Connections "Startup"
- Connections "Startup"
- Re: Can't explain db size
- Re: Estimation row error
- Re: Estimation row error
- Re: Selectivity for lopsided foreign key columns
- Re: Terrible plan choice for view with distinct on clause
- Re: Terrible plan choice for view with distinct on clause
- Re: Can't explain db size
- Re: Terrible plan choice for view with distinct on clause
- Terrible plan choice for view with distinct on clause
- Re: Selectivity for lopsided foreign key columns
- Re: Can't explain db size
- Re: Estimation row error
- Re: Estimation row error
- Selectivity for lopsided foreign key columns
- Re: Estimation row error
- Re: Estimation row error
- Re: Can't explain db size
- Re: Estimation row error
- From: Gunnar "Nick" Bluth
- Re: Can't explain db size
- Can't explain db size
- Re: Estimation row error
- Re: Estimation row error
- From: Gunnar "Nick" Bluth
- Re: Estimation row error
- Re: Performance difference between Slon master and slave
- Re: Getting an optimal plan on the first execution of a pl/pgsql function
- Re: Getting an optimal plan on the first execution of a pl/pgsql function
- Re: Getting an optimal plan on the first execution of a pl/pgsql function
- Getting an optimal plan on the first execution of a pl/pgsql function
- Re: Performance difference between Slon master and slave
- Performance difference between Slon master and slave
- Re: Advise needed for a join query with a where conditional
- Re: partitioned table set and indexes
- Re: partitioned table set and indexes
- Re: partitioned table set and indexes
- Re: Advise needed for a join query with a where conditional
- Re: checkpoints, proper config
- Re: checkpoints, proper config
- Re: partitioned table set and indexes
- Re: partitioned table set and indexes
- Re: partitioned table set and indexes
- Re: partitioned table set and indexes
- Re: partitioned table set and indexes
- partitioned table set and indexes
- Re: Estimation row error
- Estimation row error
- Re: Advise needed for a join query with a where conditional
- Advise needed for a join query with a where conditional
- Re: checkpoints, proper config
- Re: checkpoints, proper config
- Re: checkpoints, proper config
- Re: checkpoints, proper config
- Re: checkpoints, proper config
- postgresql upgrade from 9.3 to 9.4 error
- Re: checkpoints, proper config
- Re: checkpoints, proper config
- Re: checkpoints, proper config
- checkpoints, proper config
- Re: Slow Index Creation, why is it not consuming more memory.
- Slow Index Creation, why is it not consuming more memory.
- ossp-uuid: Performance considerations for different UUID approaches?
- Re: Index scan cost calculation
- Re: Index scan cost calculation
- Re: Index scan cost calculation
- Re: Index scan cost calculation
- Re: Index scan cost calculation
- Re: Query that took a lot of time in Postgresql when not using trim in order by
- Re: Query that took a lot of time in Postgresql when not using trim in order by
- Re: Index scan cost calculation
- Re: Index scan cost calculation
- Re: Index scan cost calculation
- Re: Index scan cost calculation
- Re: Index scan cost calculation
- Index scan cost calculation
- Re: No index only scan on md5 index
- Re: No index only scan on md5 index
- Re: No index only scan on md5 index
- Re: No index only scan on md5 index
- Re: No index only scan on md5 index
- No index only scan on md5 index
- Re: Query that took a lot of time in Postgresql when not using trim in order by
- Re: Query that took a lot of time in Postgresql when not using trim in order by
- Re: Query that took a lot of time in Postgresql when not using trim in order by
- Query that took a lot of time in Postgresql when not using trim in order by
- Re: Why is now()::date so much faster than current_date
- Re: Why is now()::date so much faster than current_date
- Why is now()::date so much faster than current_date
- Re: Recursive query performance issue
- Re: Recursive query performance issue
- Re: Queries getting canceled inside a proc that seems to slow down randomly
- Re: Hanging query on a fresh restart
- Re: Simple delete query is taking too long (never ends)
- Re: Simple delete query is taking too long (never ends)
- Re: Simple delete query is taking too long (never ends)
- Re: Simple delete query is taking too long (never ends)
- Re: Simple delete query is taking too long (never ends)
- Re: Simple delete query is taking too long (never ends)
- Re: Simple delete query is taking too long (never ends)
- Re: Simple delete query is taking too long (never ends)
- Simple delete query is taking too long (never ends)
- Queries getting canceled inside a proc that seems to slow down randomly
- Re: Slow 3 Table Join with v bad row estimate
- Hanging query on a fresh restart
- Re: Slow 3 Table Join with v bad row estimate
- Re: Slow 3 Table Join with v bad row estimate
- Re: Slow 3 Table Join with v bad row estimate
- Re: Slow 3 Table Join with v bad row estimate
- Re: Slow 3 Table Join with v bad row estimate
- Slow 3 Table Join with v bad row estimate
- Re: querying jsonb for arrays inside a hash
- Re: querying jsonb for arrays inside a hash
- querying jsonb for arrays inside a hash
- Re: HASH
- Re: Yet another abort-early plan disaster on 9.3
- HASH
- Re: Slow query in trigger function
- Re: GIN index always doing Re-check condition, postgres 9.1
- Re: GIN index always doing Re-check condition, postgres 9.1
- Re: GIN index always doing Re-check condition, postgres 9.1
- Re: Slow query in trigger function
- Re: Slow query in trigger function
- Re: Slow query in trigger function
- Re: PostgreSQL limitation
- PostgreSQL limitation
- Slow query in trigger function
- Re: GIN index always doing Re-check condition, postgres 9.1
- Re: GIN index always doing Re-check condition, postgres 9.1
- GIN index always doing Re-check condition, postgres 9.1
- Re: Query optimizer plans with very small selectivity estimates
- Re: Query optimizer plans with very small selectivity estimates
- Query optimizer plans with very small selectivity estimates
- Re: Scalability to more than 64 cores With PG 9.4 and RHEL 7.1 Kernel 3.10
- Re: Query planner wants to use seq scan
- Re: Query planner wants to use seq scan
- Scalability to more than 64 cores With PG 9.4 and RHEL 7.1 Kernel 3.10
- Re: Query planner wants to use seq scan
- Re: Partition Constraint Exclusion Limits
- Re: Query planner wants to use seq scan
- Re: Partition Constraint Exclusion Limits
- Re: Partition Constraint Exclusion Limits
- Partition Constraint Exclusion Limits
- Re: Query planner wants to use seq scan
- Re: Query planner wants to use seq scan
- Re: Query planner wants to use seq scan
- Re: Query planner wants to use seq scan
- Re: Query planner wants to use seq scan
- Re: Query planner wants to use seq scan
- Re: Query planner wants to use seq scan
- Re: Query planner wants to use seq scan
- Re: Query planner wants to use seq scan
- Query planner wants to use seq scan
- Re: GroupAggregate and Integer Arrays
- Re: GroupAggregate and Integer Arrays
- Re: Recursive query performance issue
- Re: Recursive query performance issue
- Re: Recursive query performance issue
- Re: Recursive query performance issue
- Re: Recursive query performance issue
- Re: Recursive query performance issue
- Re: GroupAggregate and Integer Arrays
- Re: GroupAggregate and Integer Arrays
- Re: Recursive query performance issue
- Re: GroupAggregate and Integer Arrays
- Re: GroupAggregate and Integer Arrays
- Re: GroupAggregate and Integer Arrays
- GroupAggregate and Integer Arrays
- Re: Recursive query performance issue
- Re: Recursive query performance issue
- Re: Recursive query performance issue
- Re: Recursive query performance issue
- Re: Recursive query performance issue
- Re: Recursive query performance issue
- Re: Recursive query performance issue
- Recursive query performance issue
- Re: SELECT slows down on sixth execution
- Re: SELECT slows down on sixth execution
- Re: SELECT slows down on sixth execution
- Re: SELECT slows down on sixth execution
- Re: SELECT slows down on sixth execution
- Re: One long transaction or multiple short transactions?
- Re: One long transaction or multiple short transactions?
- Re: One long transaction or multiple short transactions?
- Re: SELECT slows down on sixth execution
- Re: SELECT slows down on sixth execution
- Re: SELECT slows down on sixth execution
- Re: SELECT slows down on sixth execution
- Re: SELECT slows down on sixth execution
- Re: query partitioned table is very slow
- query partitioned table is very slow
- Re: SELECT slows down on sixth execution
- Re: SELECT slows down on sixth execution
- Re: SELECT slows down on sixth execution
- Re: SELECT slows down on sixth execution
- SELECT slows down on sixth execution
- Re: Having some problems with concurrent COPY commands
- Re: Having some problems with concurrent COPY commands
- Re: Having some problems with concurrent COPY commands
- Re: Having some problems with concurrent COPY commands
- Re: Having some problems with concurrent COPY commands
- V8 optimisation (if you're using javascript in postgres)
- Re: Having some problems with concurrent COPY commands
- Re: Having some problems with concurrent COPY commands
- Re: Having some problems with concurrent COPY commands
- Having some problems with concurrent COPY commands
- Re: 3000x Slower query when using Foreign Data Wrapper vs. local
- Re: 3000x Slower query when using Foreign Data Wrapper vs. local
- Re: 3000x Slower query when using Foreign Data Wrapper vs. local
- Re: 3000x Slower query when using Foreign Data Wrapper vs. local
- 3000x Slower query when using Foreign Data Wrapper vs. local
- Re: LIMIT 1 poor query plan
- Re: LIMIT 1 poor query plan
- LIMIT 1 poor query plan
- Re: Re: Multi processor server overloads occationally with system process while running postgresql-9.4
- Re: One long transaction or multiple short transactions?
- Re: One long transaction or multiple short transactions?
- Re: One long transaction or multiple short transactions?
- Re: One long transaction or multiple short transactions?
- Re: One long transaction or multiple short transactions?
- Re: One long transaction or multiple short transactions?
- Re: large object write performance
- From: Bram Van Steenlandt
- Re: large object write performance
- Re: large object write performance
- From: Bram Van Steenlandt
- Re: large object write performance
- Re: large object write performance
- From: Bram Van Steenlandt
- Re: large object write performance
- From: Bram Van Steenlandt
- Re: large object write performance
- Re: large object write performance
- From: Bram Van Steenlandt
- Re: large object write performance
- Re: large object write performance
- Re: large object write performance
- large object write performance
- From: Bram Van Steenlandt
- Re: One long transaction or multiple short transactions?
- Re: One long transaction or multiple short transactions?
- Re: shared-buffers set to 24GB but the RAM only use 4-5 GB average
- Re: shared-buffers set to 24GB but the RAM only use 4-5 GB average
- Re: shared-buffers set to 24GB but the RAM only use 4-5 GB average
- Re: Re: Multi processor server overloads occationally with system process while running postgresql-9.4
- Re: shared-buffers set to 24GB but the RAM only use 4-5 GB average
- Re: Multi processor server overloads occationally with system process while running postgresql-9.4
- Re: shared-buffers set to 24GB but the RAM only use 4-5 GB average
- Re: shared-buffers set to 24GB but the RAM only use 4-5 GB average
- Re: One long transaction or multiple short transactions?
- Re: shared-buffers set to 24GB but the RAM only use 4-5 GB average
- One long transaction or multiple short transactions?
- Re: shared-buffers set to 24GB but the RAM only use 4-5 GB average
- Re: shared-buffers set to 24GB but the RAM only use 4-5 GB average
- Re: shared-buffers set to 24GB but the RAM only use 4-5 GB average
- shared-buffers set to 24GB but the RAM only use 4-5 GB average
- Re: Multi processor server overloads occationally with system process while running postgresql-9.4
- Re: Multi processor server overloads occationally with system process while running postgresql-9.4
- Re: Multi processor server overloads occationally with system process while running postgresql-9.4
- Re: Multi processor server overloads occationally with system process while running postgresql-9.4
- Multi processor server overloads occationally with system process while running postgresql-9.4
- Re: Queries Per Second (QPS)
- Re: dump restoration performance
- dump restoration performance
- Re: Performance problem with gin index
- Re: Performance problem with gin index
- Re: Another parallel postgres project...
- Re: Performance problem with gin index
- Performance problem with gin index
- Another parallel postgres project...
- Re: Queries Per Second (QPS)
- Re: Queries Per Second (QPS)
- Re: Queries Per Second (QPS)
- Queries Per Second (QPS)
- Re: Occasional Really Slow Running Updates/Inserts
- Re: degrading inser performance
- Re: Occasional Really Slow Running Updates/Inserts
- Occasional Really Slow Running Updates/Inserts
- Re: degrading inser performance
- Re: degrading inser performance
- From: Matheus de Oliveira
- Re: degrading inser performance
- Re: degrading inser performance
- degrading inser performance
- Re: VACUUM VERBOSE ANALYZE taking long time to process.
- VACUUM VERBOSE ANALYZE taking long time to process.
- Re: Server slowing down over time
- Announcing the public availability of the TPCx-V prototype
- Re: pg_stat_all_indexes understand
- Re: query with pg_trgm sometimes very slow
- Re: query with pg_trgm sometimes very slow
- Re: query with pg_trgm sometimes very slow
- Re: Server slowing down over time
- Re: Server slowing down over time
- Re: query with pg_trgm sometimes very slow
- Re: PostgreSQL Tuning for Messaging/Messenger/Chatting Application
- From: Sridhar N Bamandlapally
- Re: Server slowing down over time
- Server slowing down over time
- Re: query with pg_trgm sometimes very slow
- query with pg_trgm sometimes very slow
- PostgreSQL Tuning for Messaging/Messenger/Chatting Application
- Re: [PERFORM] Re: Query > 1000× slowdown after adding datetime comparison
- Re: [PERFORM] Re: Query > 1000× slowdown after adding datetime comparison
- Re: Re: Query > 1000× slowdown after adding datetime comparison
- Re: [PERFORM] Re: Query > 1000× slowdown after adding datetime comparison
- Re: Re: Query > 1000× slowdown after adding datetime comparison
- Re: [PERFORM] Re: Query > 1000× slowdown after adding datetime comparison
- Re: Re: Query > 1000× slowdown after adding datetime comparison
- Re: [PERFORM] Re: Query > 1000× slowdown after adding datetime comparison
- Re: Re: Query > 1000× slowdown after adding datetime comparison
- Re: [PERFORM] Re: Query > 1000× slowdown after adding datetime comparison
- Re: [PERFORM] Re: Query > 1000× slowdown after adding datetime comparison
- Re: Query > 1000× slowdown after adding datetime comparison
- Re: Query > 1000× slowdown after adding datetime comparison
- Re: [PERFORM] Query > 1000× slowdown after adding datetime comparison
- Re: Query > 1000× slowdown after adding datetime comparison
- Query > 1000× slowdown after adding datetime comparison
- Re: is there any way we can push join predicate into inner table
- is there any way we can push join predicate into inner table
- From: =?gb18030?b?sKTM38jL?=
- Re: Gist indexing performance with cidr types
- From: Henrik Thostrup Jensen
- Re: Gist indexing performance with cidr types
- Re: Gist indexing performance with cidr types
- From: Henrik Thostrup Jensen
- Re: Gist indexing performance with cidr types
- From: Henrik Thostrup Jensen
- Re: Index creation running now for 14 hours
- Re: Index creation running now for 14 hours
- Re: Index creation running now for 14 hours
- Re: Index creation running now for 14 hours
- Re: Index creation running now for 14 hours
- Re: Index creation running now for 14 hours
- Re: Index creation running now for 14 hours
- Re: Index creation running now for 14 hours
- Re: Index creation running now for 14 hours
- Index creation running now for 14 hours
- Re: Gist indexing performance with cidr types
- Re: Gist indexing performance with cidr types
- Re: Gist indexing performance with cidr types
- From: Henrik Thostrup Jensen
- Re: Gist indexing performance with cidr types
- Re: Gist indexing performance with cidr types
- From: Henrik Thostrup Jensen
- Re: Gist indexing performance with cidr types
- From: Henrik Thostrup Jensen
- Re: Gist indexing performance with cidr types
- Re: Long running query: How to monitor the progress
- Gist indexing performance with cidr types
- From: Henrik Thostrup Jensen
- Long running query: How to monitor the progress
- Re: query not using GIN index
- Re: query not using GIN index
- Re: query not using GIN index
- Re: problem with select *
- Re: Performance bottleneck due to array manipulation
- Re: problem with select *
- From: Andreas Joseph Krogh
- Re: problem with select *
- problem with select *
- Re: query not using GIN index
- query not using GIN index
- Re: Performance bottleneck due to array manipulation
- Re: Performance bottleneck due to array manipulation
- Re: Performance bottleneck due to array manipulation
- Performance bottleneck due to array manipulation
- Re: Most efficient way of querying M 'related' tables where N out of M may contain the key
- Re: Most efficient way of querying M 'related' tables where N out of M may contain the key
- Re: Most efficient way of querying M 'related' tables where N out of M may contain the key
- Most efficient way of querying M 'related' tables where N out of M may contain the key
- Re: incredible surprise news from intel/micron right now...
- Re: Strange query stalls on replica in 9.3.9
- Re: Strange query stalls on replica in 9.3.9
- Re: Strange query stalls on replica in 9.3.9
- Re: Slow Query
- Re: Slow Query
- Re: Slow Query
- Re: Strange query stalls on replica in 9.3.9
- Re: Strange query stalls on replica in 9.3.9
- Strange query stalls on replica in 9.3.9
- Re: Slow Query
- Re: Slow Query
- Re: Slow Query
- Re: Query Plan Performance on Partitioned Table
- Re: Query Plan Performance on Partitioned Table
- Re: Slow Query
- Re: Slow Query
- Re: Slow Query
- Slow Query
- Re: Query Plan Performance on Partitioned Table
- Re: Query Plan Performance on Partitioned Table
- Re: Query Plan Performance on Partitioned Table
- Re: Query Plan Performance on Partitioned Table
- Re: Query Plan Performance on Partitioned Table
- Re: Query Plan Performance on Partitioned Table
- Re: Query Plan Performance on Partitioned Table
- Re: Query Plan Performance on Partitioned Table
- Re: Query Plan Performance on Partitioned Table
- Query Plan Performance on Partitioned Table
- Re: Slow HashAggregate/cache access
- Re: Slow HashAggregate/cache access
- From: Andreas Joseph Krogh
- Re: Slow HashAggregate/cache access
- From: Alexandre de Arruda Paes
- Re: Slow HashAggregate/cache access
- From: Alexandre de Arruda Paes
- Re: Slow HashAggregate/cache access
- Re: Slow HashAggregate/cache access
- Re: Slow HashAggregate/cache access
- From: Andreas Joseph Krogh
- Re: Slow HashAggregate/cache access
- From: Alexandre de Arruda Paes
- Re: Slow HashAggregate/cache access
- From: Andreas Joseph Krogh
- Re: Slow HashAggregate/cache access
- From: Alexandre de Arruda Paes
- Re: Slow HashAggregate/cache access
- Re: Slow HashAggregate/cache access
- Re: Performance issue with NestedLoop query
- Re: Performance issue with NestedLoop query
- Slow HashAggregate/cache access
- From: Alexandre de Arruda Paes
- Re: Performance issue with NestedLoop query
- Re: Performance issue with NestedLoop query
- From: Matheus de Oliveira
- Re: Performance issue with NestedLoop query
- From: Matheus de Oliveira
- Re: Performance issue with NestedLoop query
- Re: Performance issue with NestedLoop query
- Performance issue with NestedLoop query
- Re: Are many idle connections bad?
- incredible surprise news from intel/micron right now...
- Re: autofreeze/vacuuming - avoiding the random performance hit
- Re: autofreeze/vacuuming - avoiding the random performance hit
- autofreeze/vacuuming - avoiding the random performance hit
- Re: Any ideas how can I speed up this query?
- Re: Any ideas how can I speed up this query?
- Any ideas how can I speed up this query?
- Re: Are many idle connections bad?
- Re: Are many idle connections bad?
- Re: Are many idle connections bad?
- Are many idle connections bad?
- Re: hyperthreadin low performance
- Re: bitmap heap scan recheck for gin/fts with no lossy blocks
- Re: bitmap heap scan recheck for gin/fts with no lossy blocks
- Re: bitmap heap scan recheck for gin/fts with no lossy blocks
- bitmap heap scan recheck for gin/fts with no lossy blocks
- parallelisation provides postgres performance (script example + ppt slides)
- Re: hyperthreadin low performance (and some discussion about benchmarking)
- Re: hyperthreadin low performance
- Re: How to find the culprit in server load spikes?
- Re: How to find the culprit in server load spikes?
- How to find the culprit in server load spikes?
- Re: hyperthreadin low performance
- Re: hyperthreadin low performance
- hyperthreadin low performance
- From: Jeison Bedoya Delgado
- Re: Different plan for very similar queries
- Re: intel s3500 -- hot stuff
- Re: Insert vs Update
- Re: Insert vs Update
- Re: Insert vs Update
- Re: Insert vs Update
- Re: Insert vs Update
- Re: Insert vs Update
- Re: Insert vs Update
- Re: Insert vs Update
- Re: Insert vs Update
- Re: Insert vs Update
- Re: Insert vs Update
- Insert vs Update
- Re: Query planner not using indexes with JOIN query and OR clause
- Re: Query planner not using indexes with JOIN query and OR clause
- Re: [ADMIN] could not create shared memory segment: Invalid argument
- Re: [ADMIN] could not create shared memory segment: Invalid argument
- From: Ryan King - NOAA Affiliate
- Re: Query planner not using indexes with JOIN query and OR clause
- Query planner not using indexes with JOIN query and OR clause
- Re: Hmmm... why does CPU-intensive pl/pgsql code parallelise so badly when queries parallelise fine? Anyone else seen this?
- Re: QUERY PLANNER - Indexe mono column VS composite Index
- Re: QUERY PLANNER - Indexe mono column VS composite Index
- Re: QUERY PLANNER - Indexe mono column VS composite Index
- QUERY PLANNER - Indexe mono column VS composite Index
- Re: pg_stat_all_indexes understand
- Re: Hmmm... why does CPU-intensive pl/pgsql code parallelise so badly when queries parallelise fine? Anyone else seen this?
- Re: [BUGS] BUG #13493: pl/pgsql doesn't scale with cpus (PG9.3, 9.4)
- Re: Hmmm... why does CPU-intensive pl/pgsql code parallelise so badly when queries parallelise fine? Anyone else seen this?
- Re: Hmmm... why does pl/pgsql code parallelise so badly when queries parallelise fine? Anyone else seen this?
- Re: Hmmm... why does CPU-intensive pl/pgsql code parallelise so badly when queries parallelise fine? Anyone else seen this?
- Re: Hmmm... why does CPU-intensive pl/pgsql code parallelise so badly when queries parallelise fine? Anyone else seen this?
- Re: Hmmm... why does CPU-intensive pl/pgsql code parallelise so badly when queries parallelise fine? Anyone else seen this?
- Re: Hmmm... why does CPU-intensive pl/pgsql code parallelise so badly when queries parallelise fine? Anyone else seen this?
- Re: Hmmm... why does CPU-intensive pl/pgsql code parallelise so badly when queries parallelise fine? Anyone else seen this?
- pg_stat_all_indexes understand
- Re: Hmmm... why does pl/pgsql code parallelise so badly when queries parallelise fine? Anyone else seen this?
- Re: Hmmm... why does pl/pgsql code parallelise so badly when queries parallelise fine? Anyone else seen this?
- Re: Hmmm... why does CPU-intensive pl/pgsql code parallelise so badly when queries parallelise fine? Anyone else seen this?
- Re: Hmmm... why does CPU-intensive pl/pgsql code parallelise so badly when queries parallelise fine? Anyone else seen this?
- Re: Hmmm... why does CPU-intensive pl/pgsql code parallelise so badly when queries parallelise fine? Anyone else seen this?
- Re: Hmmm... why does CPU-intensive pl/pgsql code parallelise so badly when queries parallelise fine? Anyone else seen this?
- Re: Hmmm... why does CPU-intensive pl/pgsql code parallelise so badly when queries parallelise fine? Anyone else seen this?
- Re: Hmmm... why does CPU-intensive pl/pgsql code parallelise so badly when queries parallelise fine? Anyone else seen this?
- Re: Hmmm... why does CPU-intensive pl/pgsql code parallelise so badly when queries parallelise fine? Anyone else seen this?
- Re: Hmmm... why does CPU-intensive pl/pgsql code parallelise so badly when queries parallelise fine? Anyone else seen this?
- Re: Hmmm... why does CPU-intensive pl/pgsql code parallelise so badly when queries parallelise fine? Anyone else seen this?
- Re: Hmmm... why does CPU-intensive pl/pgsql code parallelise so badly when queries parallelise fine? Anyone else seen this?
- Re: Hmmm... why does CPU-intensive pl/pgsql code parallelise so badly when queries parallelise fine? Anyone else seen this?
- Re: Hmmm... why does pl/pgsql code parallelise so badly when queries parallelise fine? Anyone else seen this?
- Re: Hmmm... why does pl/pgsql code parallelise so badly when queries parallelise fine? Anyone else seen this?
- Re: Hmmm... why does CPU-intensive pl/pgsql code parallelise so badly when queries parallelise fine? Anyone else seen this?
- Re: wildcard text filter switched to boolean column, performance is way worse
- Re: Hmmm... why does CPU-intensive pl/pgsql code parallelise so badly when queries parallelise fine? Anyone else seen this?
- Re: Hmmm... why does CPU-intensive pl/pgsql code parallelise so badly when queries parallelise fine? Anyone else seen this?
- Hmmm... why does CPU-intensive pl/pgsql code parallelise so badly when queries parallelise fine? Anyone else seen this?
- Re: Hmmm... why does pl/pgsql code parallelise so badly when queries parallelise fine? Anyone else seen this?
- Re: Hmmm... why does pl/pgsql code parallelise so badly when queries parallelise fine? Anyone else seen this?
- Re: New server: SSD/RAID recommendations?
- Re: New server: SSD/RAID recommendations?
- Re: New server: SSD/RAID recommendations?
- Re: New server: SSD/RAID recommendations?
- Re: New server: SSD/RAID recommendations?
- Re: New server: SSD/RAID recommendations?
- Re: New server: SSD/RAID recommendations?
- Re: New server: SSD/RAID recommendations?
- Re: New server: SSD/RAID recommendations?
- Re: New server: SSD/RAID recommendations?
- Re: Sudden connection and load average spikes with postgresql 9.3
- Re: New server: SSD/RAID recommendations?
- Re: New server: SSD/RAID recommendations?
- Re: New server: SSD/RAID recommendations?
- Re: New server: SSD/RAID recommendations?
- Re: New server: SSD/RAID recommendations?
- Re: New server: SSD/RAID recommendations?
- Re: wildcard text filter switched to boolean column, performance is way worse
- Re: New server: SSD/RAID recommendations?
- Re: wildcard text filter switched to boolean column, performance is way worse
- Re: wildcard text filter switched to boolean column, performance is way worse
- Re: New server: SSD/RAID recommendations?
- Re: New server: SSD/RAID recommendations?
- wildcard text filter switched to boolean column, performance is way worse
- Re: New server: SSD/RAID recommendations?
- Re: New server: SSD/RAID recommendations?
- Re: New server: SSD/RAID recommendations?
- Re: New server: SSD/RAID recommendations?
- Re: New server: SSD/RAID recommendations?
- Re: New server: SSD/RAID recommendations?
- Re: New server: SSD/RAID recommendations?
- Re: New server: SSD/RAID recommendations?
- Re: Sudden connection and load average spikes with postgresql 9.3
- Re: New server: SSD/RAID recommendations?
- Re: New server: SSD/RAID recommendations?
- Re: New server: SSD/RAID recommendations?
- Re: New server: SSD/RAID recommendations?
- Re: New server: SSD/RAID recommendations?
- Re: 9.5alpha1 vs 9.4
- Re: New server: SSD/RAID recommendations?
- Re: New server: SSD/RAID recommendations?
- Re: 9.5alpha1 vs 9.4
- Re: Hmmm... why does pl/pgsql code parallelise so badly when queries parallelise fine? Anyone else seen this?
- Re: 9.5alpha1 vs 9.4
- Re: pgbouncer issue
- From: Greg Sabino Mullane
- Re: 9.5alpha1 vs 9.4
- Re: 9.5alpha1 vs 9.4
- Re: 9.5alpha1 vs 9.4
- 9.5alpha1 vs 9.4
- Re: Hmmm... why does pl/pgsql code parallelise so badly when queries parallelise fine? Anyone else seen this?
- Hmmm... why does pl/pgsql code parallelise so badly when queries parallelise fine? Anyone else seen this?
- Re: Sudden connection and load average spikes with postgresql 9.3
- Re: Sudden connection and load average spikes with postgresql 9.3
- Re: Sudden connection and load average spikes with postgresql 9.3
- Re: Sudden connection and load average spikes with postgresql 9.3
- Re: New server: SSD/RAID recommendations?
- Re: New server: SSD/RAID recommendations?
- Re: New server: SSD/RAID recommendations?
- Re: New server: SSD/RAID recommendations?
- Re: Sudden connection and load average spikes with postgresql 9.3
- Re: New server: SSD/RAID recommendations?
- Re: New server: SSD/RAID recommendations?
- Re: New server: SSD/RAID recommendations?
- Re: New server: SSD/RAID recommendations?
- From: Andreas Joseph Krogh
- New server: SSD/RAID recommendations?
- Re: Sudden connection and load average spikes with postgresql 9.3
- Re: Sudden connection and load average spikes with postgresql 9.3
- Re: Sudden connection and load average spikes with postgresql 9.3
- Sudden connection and load average spikes with postgresql 9.3
- Does anyone have python code which digests pgbench -r output?
- Re: Slow query (planner insisting on using 'external merge' sort type)
- pgbouncer issue
[Index of Archives]
[Postgresql General]
[Postgresql PHP]
[PHP Home]
[PHP on Windows]
[Yosemite]