Postgres Performance Date Index
[Prev Page][Next Page]
- Re: Huge overestimation in rows expected results in bad plan
- Re: anti-join chosen even when slower than old plan
- Re: anti-join chosen even when slower than old plan
- Re: anti-join chosen even when slower than old plan
- Re: Huge overestimation in rows expected results in bad plan
- Re: Huge overestimation in rows expected results in bad plan
- Huge overestimation in rows expected results in bad plan
- anti-join chosen even when slower than old plan
- Re: out of memory problem
- Re: out of memory problem
- out of memory problem
- Re: Defaulting wal_sync_method to fdatasync on Linux for 9.1?
- Re: Defaulting wal_sync_method to fdatasync on Linux for 9.1?
- Re: Running PostgreSQL as fast as possible no matter the consequences
- Re: Running PostgreSQL as fast as possible no matter the consequences
- Re: Select * is very slow
- Re: Select * is very slow
- Re: Defaulting wal_sync_method to fdatasync on Linux for 9.1?
- Re: Defaulting wal_sync_method to fdatasync on Linux for 9.1?
- Re: Select * is very slow
- Re: Select * is very slow
- Re: Select * is very slow
- Re: Select * is very slow
- Re: Select * is very slow
- Re: Select * is very slow
- Select * is very slow
- Re: Running PostgreSQL as fast as possible no matter the consequences
- Array interface
- Help with bulk read performance
- Array interface
- Re: Defaulting wal_sync_method to fdatasync on Linux for 9.1?
- Re: Regression: 8.3 2 seconds -> 8.4 100+ seconds
- Re: questions regarding shared_buffers behavior
- Re: Defaulting wal_sync_method to fdatasync on Linux for 9.1?
- Re: questions regarding shared_buffers behavior
- Re: Defaulting wal_sync_method to fdatasync on Linux for 9.1?
- Re: Defaulting wal_sync_method to fdatasync on Linux for 9.1?
- Re: Defaulting wal_sync_method to fdatasync on Linux for 9.1?
- Re: questions regarding shared_buffers behavior
- questions regarding shared_buffers behavior
- Re: Regression: 8.3 2 seconds -> 8.4 100+ seconds
- Re: Running PostgreSQL as fast as possible no matter the consequences
- Re: postmaster consuming /lots/ of memory with hash aggregate. why?
- Re: postmaster consuming /lots/ of memory with hash aggregate. why?
- postmaster consuming /lots/ of memory with hash aggregate. why?
- Re: Defaulting wal_sync_method to fdatasync on Linux for 9.1?
- Re: Defaulting wal_sync_method to fdatasync on Linux for 9.1?
- Re: Major Linux performance regression; shouldn't we be worried about RHEL6?
- Re: Major Linux performance regression; shouldn't we be worried about RHEL6?
- Re: Defaulting wal_sync_method to fdatasync on Linux for 9.1?
- Re: Defaulting wal_sync_method to fdatasync on Linux for 9.1?
- Re: Simple (hopefully) throughput question?
- Re: Simple (hopefully) throughput question?
- Re: Major Linux performance regression; shouldn't we be worried about RHEL6?
- Re: Defaulting wal_sync_method to fdatasync on Linux for 9.1?
- Re: Defaulting wal_sync_method to fdatasync on Linux for 9.1?
- Re: Defaulting wal_sync_method to fdatasync on Linux for 9.1?
- Re: Major Linux performance regression; shouldn't we be worried about RHEL6?
- Re: Bufer cache replacement LRU algorithm?
- Re: Major Linux performance regression; shouldn't we be worried about RHEL6?
- Re: Major Linux performance regression; shouldn't we be worried about RHEL6?
- Re: Major Linux performance regression; shouldn't we be worried about RHEL6?
- Re: Major Linux performance regression; shouldn't we be worried about RHEL6?
- Major Linux performance regression; shouldn't we be worried about RHEL6?
- Re: Simple (hopefully) throughput question?
- Re: Running PostgreSQL as fast as possible no matter the consequences
- Re: Running PostgreSQL as fast as possible no matter the consequences
- Re: Running PostgreSQL as fast as possible no matter the consequences
- Re: Running PostgreSQL as fast as possible no matter the consequences
- Re: Running PostgreSQL as fast as possible no matter the consequences
- From: Guillaume Cottenceau
- Re: Running PostgreSQL as fast as possible no matter the consequences
- From: Guillaume Cottenceau
- Re: Running PostgreSQL as fast as possible no matter the consequences
- Re: Running PostgreSQL as fast as possible no matter the consequences
- Re: Running PostgreSQL as fast as possible no matter the consequences
- Re: Running PostgreSQL as fast as possible no matter the consequences
- Re: Running PostgreSQL as fast as possible no matter the consequences
- Re: Running PostgreSQL as fast as possible no matter the consequences
- Re: Running PostgreSQL as fast as possible no matter the consequences
- Re: Running PostgreSQL as fast as possible no matter the consequences
- Re: Running PostgreSQL as fast as possible no matter the consequences
- From: Guillaume Cottenceau
- Re: Running PostgreSQL as fast as possible no matter the consequences
- Re: Running PostgreSQL as fast as possible no matter the consequences
- Running PostgreSQL as fast as possible no matter the consequences
- Re: Simple (hopefully) throughput question?
- Re: Simple (hopefully) throughput question?
- Re: Simple (hopefully) throughput question?
- Re: Simple (hopefully) throughput question?
- Re: Simple (hopefully) throughput question?
- Re: Simple (hopefully) throughput question?
- Re: Simple (hopefully) throughput question?
- Re: Simple (hopefully) throughput question?
- Re: Simple (hopefully) throughput question?
- Re: Simple (hopefully) throughput question?
- Re: Simple (hopefully) throughput question?
- Re: Simple (hopefully) throughput question?
- Re: Simple (hopefully) throughput question?
- Re: Bufer cache replacement LRU algorithm?
- Simple (hopefully) throughput question?
- Re: Bufer cache replacement LRU algorithm?
- Bufer cache replacement LRU algorithm?
- Re: Test
- Re: Array interface
- Re: A query become very slow after upgrade from 8.1.10 to 8.4.5
- Re: Array interface
- Re: A query become very slow after upgrade from 8.1.10 to 8.4.5
- Array interface
- Test
- Re: Insert performance with composite index
- Re: Insert performance with composite index
- Re: Insert performance with composite index
- From: hubert depesz lubaczewski
- Re: Insert performance with composite index
- Re: Insert performance with composite index
- From: hubert depesz lubaczewski
- A query become very slow after upgrade from 8.1.10 to 8.4.5
- Re: Insert performance with composite index
- Re: Insert performance with composite index
- Re: Insert performance with composite index
- Re: Insert performance with composite index
- Re: Insert performance with composite index
- Re: Insert performance with composite index
- Re: Insert performance with composite index
- Re: Insert performance with composite index
- Re: Insert performance with composite index
- Re: Insert performance with composite index
- Insert performance with composite index
- Re: Defaulting wal_sync_method to fdatasync on Linux for 9.1?
- Re: Defaulting wal_sync_method to fdatasync on Linux for 9.1?
- Re: Defaulting wal_sync_method to fdatasync on Linux for 9.1?
- Re: Defaulting wal_sync_method to fdatasync on Linux for 9.1?
- Defaulting wal_sync_method to fdatasync on Linux for 9.1?
- Re: Slow Query- Bad Row Estimate
- Re: Slow Query- Bad Row Estimate
- Re: Slow Query- Bad Row Estimate
- Re: Slow Query- Bad Row Estimate
- Re: Slow Query- Bad Row Estimate
- Re: Slow Query- Bad Row Estimate
- Re: Slow Query- Bad Row Estimate
- Re: Slow Query- Bad Row Estimate
- Re: Slow Query- Bad Row Estimate
- Re: BBU Cache vs. spindles
- Re: Slow Query- Bad Row Estimate
- Slow Query- Bad Row Estimate
- Re: BBU Cache vs. spindles
- Re: MVCC and Implications for (Near) Real-Time Application
- Re: BBU Cache vs. spindles
- Re: typoed column name, but postgres didn't grump
- Re: BBU Cache vs. spindles
- Re: typoed column name, but postgres didn't grump
- Re: temporary tables, indexes, and query plans
- Re: typoed column name, but postgres didn't grump
- Re: MVCC and Implications for (Near) Real-Time Application
- Re: MVCC and Implications for (Near) Real-Time Application
- Re: temporary tables, indexes, and query plans
- Re: temporary tables, indexes, and query plans
- Re: Postgres insert performance and storage requirement compared to Oracle
- Re: Stored procedure declared as VOLATILE => no good optimization is done
- MVCC and Implications for (Near) Real-Time Application
- CPUs for new databases
- From: Christian Elmerot @ One.com
- typoed column name, but postgres didn't grump
- Re: BBU Cache vs. spindles
- Re: partitioning question 1
- Re: partitioning question 1
- Re: BBU Cache vs. spindles
- Re: BBU Cache vs. spindles
- Re: BBU Cache vs. spindles
- Re: partitioning question 1
- Re: Massive update, memory usage
- From: Emanuele Bracci Poste
- Re: Massive update, memory usage
- Re: BBU Cache vs. spindles
- Re: partitioning question 1
- Re: partitioning question 1
- Re: BBU Cache vs. spindles
- Re: partitioning question 1
- Re: partitioning question 1
- Re: partitioning question 1
- Re: partitioning question 1
- Re: partitioning question 1
- Re: partitioning question 1
- Re: how to get the total number of records in report
- Re: how to get the total number of records in report
- Re: how to get the total number of records in report
- Re: partitioning question 1
- Re: how to get the total number of records in report
- partitioning question 1
- Re: Query much faster with enable_seqscan=0
- Re: Slow Query- Simple taking
- Re: Massive update, memory usage
- Re: How does PG know if data is in memory?
- Re: Postgres insert performance and storage requirement compared to Oracle
- Re: Slow Query- Simple taking
- Re: Slow Query- Simple taking
- Re: Slow Query- Simple taking
- Re: Slow Query- Simple taking
- Re: Slow Query- Simple taking
- Re: Slow Query- Simple taking
- Re: temporary tables, indexes, and query plans
- Re: temporary tables, indexes, and query plans
- Re: Select count(*), the sequel
- Re: Postgres insert performance and storage requirement compared to Oracle
- Re: AIX slow buffer reads
- Re: Select count(*), the sequel
- Massive update, memory usage
- Re: Postgres insert performance and storage requirement compared to Oracle
- Re: Postgres insert performance and storage requirement compared to Oracle
- Re: BBU Cache vs. spindles
- Re: Re: Postgres insert performance and storage requirement compared to Oracle
- Re: Postgres insert performance and storage requirement compared to Oracle
- Re: How does PG know if data is in memory?
- Re: Re: Postgres insert performance and storage requirement compared to Oracle
- Re: BBU Cache vs. spindles
- Re: Massive update, memory usage
- Re: AIX slow buffer reads
- Re: AIX slow buffer reads
- Re: temporary tables, indexes, and query plans
- Re: temporary tables, indexes, and query plans
- Re: Select count(*), the sequel
- Re: temporary tables, indexes, and query plans
- Re: AIX slow buffer reads
- Re: Select count(*), the sequel
- Re: Select count(*), the sequel
- Re: temporary tables, indexes, and query plans
- Re: Select count(*), the sequel
- Re: AIX slow buffer reads
- Re: CPUs for new databases
- Re: HashJoin order, hash the large or small table? Postgres likes to hash the big one, why?
- Re: Select count(*), the sequel
- Re: Postgres insert performance and storage requirement compared to Oracle
- Re: Postgres insert performance and storage requirement compared to Oracle
- Re: temporary tables, indexes, and query plans
- Re: temporary tables, indexes, and query plans
- Re: AIX slow buffer reads
- Re: HashJoin order, hash the large or small table? Postgres likes to hash the big one, why?
- Re: CPUs for new databases
- Re: temporary tables, indexes, and query plans
- Re: Massive update, memory usage
- Re: Postgres insert performance and storage requirement compared to Oracle
- Re: Postgres insert performance and storage requirement compared to Oracle
- Re: Postgres insert performance and storage requirement compared to Oracle
- Massive update, memory usage
- Re: temporary tables, indexes, and query plans
- Re: Postgres insert performance and storage requirement compared to Oracle
- Re: CPUs for new databases
- Re: temporary tables, indexes, and query plans
- Re: Postgres insert performance and storage requirement compared to Oracle
- Re: Postgres insert performance and storage requirement compared to Oracle
- Re: temporary tables, indexes, and query plans
- Re: Postgres insert performance and storage requirement compared to Oracle
- Re: Postgres insert performance and storage requirement compared to Oracle
- Re: CPUs for new databases
- Re: Postgres insert performance and storage requirement compared to Oracle
- Re: temporary tables, indexes, and query plans
- temporary tables, indexes, and query plans
- Re: AIX slow buffer reads
- Re: Regression: 8.3 2 seconds -> 8.4 100+ seconds
- Re: Postgres insert performance and storage requirement compared to Oracle
- Re: Regression: 8.3 2 seconds -> 8.4 100+ seconds
- Re: Postgres insert performance and storage requirement compared to Oracle
- Re: Postgres insert performance and storage requirement compared to Oracle
- Re: Postgres insert performance and storage requirement compared to Oracle
- Re: Running 9 in production? Sticking with 8.4.4 for a while?
- Re: Regression: 8.3 2 seconds -> 8.4 100+ seconds
- Re: Regression: 8.3 2 seconds -> 8.4 100+ seconds
- Re: Regression: 8.3 2 seconds -> 8.4 100+ seconds
- Re: Postgres insert performance and storage requirement compared to Oracle
- Re: Regression: 8.3 2 seconds -> 8.4 100+ seconds
- Regression: 8.3 2 seconds -> 8.4 100+ seconds
- Re: AIX slow buffer reads
- Re: Re: Postgres insert performance and storage requirement compared to Oracle
- Re: Postgres insert performance and storage requirement compared to Oracle
- Re: CPUs for new databases
- Re: CPUs for new databases
- Re: CPUs for new databases
- Re: BBU Cache vs. spindles
- Re: odd postgresql performance (excessive lseek)
- Re: HashJoin order, hash the large or small table? Postgres likes to hash the big one, why?
- Re: odd postgresql performance (excessive lseek)
- Re: HashJoin order, hash the large or small table? Postgres likes to hash the big one, why?
- Re: Select count(*), the sequel
- Re: CPUs for new databases
- Re: CPUs for new databases
- Re: CPUs for new databases
- Slow Query- Bad Row Estimate
- Re: Postgres insert performance and storage requirement compared to Oracle
- Re: Select count(*), the sequel
- Re: Postgres insert performance and storage requirement compared to Oracle
- Re: Select count(*), the sequel
- Re: Postgres insert performance and storage requirement compared to Oracle
- Re: Postgres insert performance and storage requirement compared to Oracle
- Re: Postgres insert performance and storage requirement compared to Oracle
- Re: AIX slow buffer reads
- Re: Postgres insert performance and storage requirement compared to Oracle
- Re: CPUs for new databases
- Re: Postgres insert performance and storage requirement compared to Oracle
- Re: CPUs for new databases
- Re: Postgres insert performance and storage requirement compared to Oracle
- From: Leonardo Francalanci
- Re: CPUs for new databases
- Re: CPUs for new databases
- Re: BBU Cache vs. spindles
- Re: BBU Cache vs. spindles
- Re: AIX slow buffer reads
- Re: Postgres insert performance and storage requirement compared to Oracle
- CPUs for new databases
- Re: BBU Cache vs. spindles
- Re: which one is faster
- Re: Auto ANALYZE criteria
- Re: No hash join across partitioned tables?
- Re: which one is faster
- Re: which one is faster
- From: Grzegorz Jaśkiewicz
- Re: which one is faster
- Re: which one is faster
- From: Grzegorz Jaśkiewicz
- Re: which one is faster
- Re: which one is faster
- Re: Postgres insert performance and storage requirement compared to Oracle
- Re: which one is faster
- which one is faster
- Re: BBU Cache vs. spindles
- Re: interpret statement log duration information
- interpret statement log duration information
- Re: Postgres insert performance and storage requirement compared to Oracle
- Re: Postgres insert performance and storage requirement compared to Oracle
- Re: Postgres insert performance and storage requirement compared to Oracle
- Re: Postgres insert performance and storage requirement compared to Oracle
- Re: AIX slow buffer reads
- Re: Postgres insert performance and storage requirement compared to Oracle
- Re: Postgres insert performance and storage requirement compared to Oracle
- Re: Postgres insert performance and storage requirement compared to Oracle
- Re: AIX slow buffer reads
- Re: Postgres insert performance and storage requirement compared to Oracle
- Re: Postgres insert performance and storage requirement compared to Oracle
- Re: Postgres insert performance and storage requirement compared to Oracle
- Re: Postgres insert performance and storage requirement compared to Oracle
- Re: Postgres insert performance and storage requirement compared to Oracle
- Re: Postgres insert performance and storage requirement compared to Oracle
- AIX slow buffer reads
- Re: Postgres insert performance and storage requirement compared to Oracle
- Re: Postgres insert performance and storage requirement compared to Oracle
- Postgres insert performance and storage requirement compared to Oracle
- Re: Useless sort by
- Re: BBU Cache vs. spindles
- Re: BBU Cache vs. spindles
- Re: BBU Cache vs. spindles
- Re: BBU Cache vs. spindles
- Re: BBU Cache vs. spindles
- Re: BBU Cache vs. spindles
- Re: BBU Cache vs. spindles
- Re: BBU Cache vs. spindles
- Re: BBU Cache vs. spindles
- Re: BBU Cache vs. spindles
- Re: BBU Cache vs. spindles
- Re: BBU Cache vs. spindles
- Re: BBU Cache vs. spindles
- Re: BBU Cache vs. spindles
- Re: BBU Cache vs. spindles
- Re: Periodically slow inserts
- Re: BBU Cache vs. spindles
- Re: Periodically slow inserts
- From: Leonardo Francalanci
- Re: BBU Cache vs. spindles
- Re: BBU Cache vs. spindles
- Re: BBU Cache vs. spindles
- Re: Slow count(*) again...
- Re: BBU Cache vs. spindles
- Re: Index scan is not working, why??
- Re: BBU Cache vs. spindles
- Re: BBU Cache vs. spindles
- Re: BBU Cache vs. spindles
- Re: BBU Cache vs. spindles
- Re: BBU Cache vs. spindles
- Experiences with running PostgreSQL on Blue Arc Network Storage
- Re: How does PG know if data is in memory?
- Re: BBU Cache vs. spindles
- Re: Slow count(*) again...
- Re: BBU Cache vs. spindles
- Re: BBU Cache vs. spindles
- Re: BBU Cache vs. spindles
- Re: BBU Cache vs. spindles
- Re: BBU Cache vs. spindles
- Re: BBU Cache vs. spindles
- Re: Periodically slow inserts
- Re: BBU Cache vs. spindles
- Re: Periodically slow inserts
- Re: New wiki page on write reliability
- Re: Periodically slow inserts
- Re: Periodically slow inserts
- Re: Periodically slow inserts
- Re: New wiki page on write reliability
- Re: Periodically slow inserts
- From: Leonardo Francalanci
- Re: Periodically slow inserts
- From: Leonardo Francalanci
- Re: Periodically slow inserts
- Re: Periodically slow inserts
- Re: New wiki page on write reliability
- New wiki page on write reliability
- Re: Index scan is not working, why??
- Re: Periodically slow inserts
- From: Leonardo Francalanci
- Re: Periodically slow inserts
- Periodically slow inserts
- Re: Index scan is not working, why??
- Re: Index scan is not working, why??
- Index scan is not working, why??
- Re: Slow count(*) again...
- Re: BBU Cache vs. spindles
- Re: Slow count(*) again...
- Re: What is postmaster doing?
- Re: BBU Cache vs. spindles
- Re: BBU Cache vs. spindles
- Re: What is postmaster doing?
- Re: What is postmaster doing?
- Re: What is postmaster doing?
- Re: What is postmaster doing?
- Re: What is postmaster doing?
- Re: What is postmaster doing?
- Re: What is postmaster doing?
- Re: What is postmaster doing?
- Re: What is postmaster doing?
- Re: What is postmaster doing?
- Re: What is postmaster doing?
- What is postmaster doing?
- Re: how to get the total number of records in report
- Re: Slow Query- Simple taking
- Re: Slow Query- Simple taking
- Re: Slow Query- Simple taking
- Slow Query- Simple taking
- Re: odd postgresql performance (excessive lseek)
- Re: odd postgresql performance (excessive lseek)
- Re: odd postgresql performance (excessive lseek)
- Re: HashJoin order, hash the large or small table? Postgres likes to hash the big one, why?
- Re: odd postgresql performance (excessive lseek)
- Re: Help with duration of statement: EXECUTE <unnamed> [PREPARE: COMMIT]
- Re: HashJoin order, hash the large or small table? Postgres likes to hash the big one, why?
- Re: how to get the total number of records in report
- Re: odd postgresql performance (excessive lseek)
- Re: odd postgresql performance (excessive lseek)
- Re: odd postgresql performance (excessive lseek)
- Re: Help with duration of statement: EXECUTE <unnamed> [PREPARE: COMMIT]
- Re: HashJoin order, hash the large or small table? Postgres likes to hash the big one, why?
- Re: how to get the total number of records in report
- Re: HashJoin order, hash the large or small table? Postgres likes to hash the big one, why?
- Re: unexpected query failure: ERROR: GIN indexes do not support whole-index scans
- HashJoin order, hash the large or small table? Postgres likes to hash the big one, why?
- Re: unexpected query failure: ERROR: GIN indexes do not support whole-index scans
- unexpected query failure: ERROR: GIN indexes do not support whole-index scans
- Re: how to get the total number of records in report
- Re: Help with duration of statement: EXECUTE <unnamed> [PREPARE: COMMIT]
- Re: No hash join across partitioned tables?
- Re: Help with duration of statement: EXECUTE <unnamed> [PREPARE: COMMIT]
- Re: Help with duration of statement: EXECUTE <unnamed> [PREPARE: COMMIT]
- Re: Select count(*), the sequel
- Re: Select count(*), the sequel
- Re: No hash join across partitioned tables?
- Select count(*), the sequel
- Help with duration of statement: EXECUTE <unnamed> [PREPARE: COMMIT]
- Re: Index scan / Index cond limitation or ?
- how to get the total number of records in report
- Re: Stored procedure declared as VOLATILE => no good optimization is done
- Re: UUID performance as primary key
- Re: Select count(*), the sequel
- Re: UUID performance as primary key
- Select count(*), the sequel
- Re: No hash join across partitioned tables?
- Re: No hash join across partitioned tables?
- Re: No hash join across partitioned tables?
- Re: No hash join across partitioned tables?
- Re: UUID performance as primary key
- Re: Slow count(*) again...
- Re: UUID performance as primary key
- Re: Stored procedure declared as VOLATILE => no good optimization is done
- UUID performance as primary key
- Re: Stored procedure declared as VOLATILE => no good optimization is done
- Re: Stored procedure declared as VOLATILE => no good optimization is done
- Re: Stored procedure declared as VOLATILE => no good optimization is done
- Re: oracle to psql migration - slow query in postgres
- Re: oracle to psql migration - slow query in postgres
- Re: help with understanding EXPLAIN and boosting performance
- Re: Index scan / Index cond limitation or ?
- Re: oracle to psql migration - slow query in postgres
- Re: oracle to psql migration - slow query in postgres
- help with understanding EXPLAIN
- Re: Auto ANALYZE criteria
- Index scan / Index cond limitation or ?
- help with understanding EXPLAIN and boosting performance
- Re: Slow count(*) again...
- Stored procedure declared as VOLATILE => no good optimization is done
- Re: Slow count(*) again...
- Re: oracle to psql migration - slow query in postgres
- Re: oracle to psql migration - slow query in postgres
- Re: oracle to psql migration - slow query in postgres
- Re: oracle to psql migration - slow query in postgres
- Re: Slow count(*) again...
- Re: oracle to psql migration - slow query in postgres
- odd postgresql performance (excessive lseek)
- Re: Slow count(*) again...
- Re: oracle to psql migration - slow query in postgres
- Re: oracle to psql migration - slow query in postgres
- Re: oracle to psql migration - slow query in postgres
- Re: oracle to psql migration - slow query in postgres
- Re: oracle to psql migration - slow query in postgres
- Re: oracle to psql migration - slow query in postgres
- Re: Slow count(*) again...
- oracle to psql migration - slow query in postgres
- Re: How does PG know if data is in memory?
- Re: Slow count(*) again...
- Re: SQL functions vs. PL/PgSQL functions
- Re: SQL functions vs. PL/PgSQL functions
- Re: Bogus startup cost for WindowAgg
- Re: Slow count(*) again...
- Re: Slow count(*) again...
- Re: Slow count(*) again...
- Re: Bogus startup cost for WindowAgg
- Re: Slow count(*) again...
- Re: Slow count(*) again...
- Re: Bogus startup cost for WindowAgg
- Re: Slow count(*) again...
- Re: Slow count(*) again...
- Re: Bogus startup cost for WindowAgg
- Re: SQL functions vs. PL/PgSQL functions
- Re: Slow count(*) again...
- Re: Slow count(*) again...
- Re: Slow count(*) again...
- Bogus startup cost for WindowAgg
- Re: SQL functions vs. PL/PgSQL functions
- Re: SQL functions vs. PL/PgSQL functions
- Re: Slow count(*) again...
- Re: Slow count(*) again...
- Re: Slow count(*) again...
- Re: Slow count(*) again...
- Re: Slow count(*) again...
- Re: Slow count(*) again...
- Re: Slow count(*) again...
- Re: Slow count(*) again...
- Re: Slow count(*) again...
- Re: Slow count(*) again...
- Re: Slow count(*) again...
- Re: Slow count(*) again...
- Re: Slow count(*) again...
- Re: Slow count(*) again...
- Re: Slow count(*) again...
- Re: SQL functions vs. PL/PgSQL functions
- Re: Slow count(*) again...
- SQL functions vs. PL/PgSQL functions
- Re: Slow count(*) again...
- Re: Slow count(*) again...
- Re: Slow count(*) again...
- Re: How does PG know if data is in memory?
- Re: How does PG know if data is in memory?
- Re: Query much faster with enable_seqscan=0
- Re: Query much faster with enable_seqscan=0
- Re: Slow count(*) again...
- Re: Slow count(*) again...
- Re: Slow count(*) again...
- Re: Slow count(*) again...
- Re: Slow count(*) again...
- Re: Slow count(*) again...
- Re: bulk load performance question
- Re: read only transactions
- bulk load performance question
- Re: read only transactions
- Re: read only transactions
- Re: read only transactions
- Re: Slow count(*) again...
- Re: Slow count(*) again...
- Re: Slow count(*) again...
- read only transactions
- Re: Slow count(*) again...
- Re: Slow count(*) again...
- Re: large dataset with write vs read clients
- Re: large dataset with write vs read clients
- Re: Slow count(*) again...
- Re: Slow count(*) again...
- Re: Slow count(*) again...
- Re: Slow count(*) again...
- Re: Slow count(*) again...
- Re: Slow count(*) again...
- Re: Slow count(*) again...
- Re: Slow count(*) again...
- Re: Slow count(*) again...
- Re: Slow count(*) again...
- Re: Slow count(*) again...
- Re: Slow count(*) again...
- Re: Slow count(*) again...
- Re: Slow count(*) again...
- Re: How does PG know if data is in memory?
- Re: How does PG know if data is in memory?
- Re: How does PG know if data is in memory?
- Re: Slow count(*) again...
- Re: How does PG know if data is in memory?
- Re: Slow count(*) again...
- Re: Slow count(*) again...
- Re: Slow count(*) again...
- Re: Slow count(*) again...
- Re: Slow count(*) again...
- Re: Slow count(*) again...
- Re: Slow count(*) again...
- Re: Runtime dependency from size of a bytea field
- Re: How does PG know if data is in memory?
- Re: Slow count(*) again...
- Re: Slow count(*) again...
- Re: Slow count(*) again...
- Re: Slow count(*) again...
- Re: Slow count(*) again...
- Re: Slow count(*) again...
- Re: Slow count(*) again...
- Re: Slow count(*) again...
- Re: Slow count(*) again...
- Re: Slow count(*) again...
- Re: Slow count(*) again...
- Re: Slow count(*) again...
- Re: Slow count(*) again...
- Re: How does PG know if data is in memory?
- Re: How does PG know if data is in memory?
- Re: Slow count(*) again...
- Re: Slow count(*) again...
- Re: Slow count(*) again...
- Re: Slow count(*) again...
- Re: Slow count(*) again...
- Re: gist indexes for distance calculations
- Re: Slow count(*) again...
- Re: Slow count(*) again...
- Re: Slow count(*) again...
- Re: XFS vs Ext3, and schedulers, for WAL
- Re: XFS vs Ext3, and schedulers, for WAL
- Re: XFS vs Ext3, and schedulers, for WAL
- Re: Slow count(*) again...
- Re: Slow count(*) again...
- Re: join order
- join order
- Re: Slow count(*) again...
- Re: Slow count(*) again...
- Re: Slow count(*) again...
- Re: Slow count(*) again...
- Re: Slow count(*) again...
- Re: Slow count(*) again...
- Re: Slow count(*) again...
- Re: Slow count(*) again...
- Re: Slow count(*) again...
- Re: Slow count(*) again...
- Re: Slow count(*) again...
- Re: Slow count(*) again...
- Re: Slow count(*) again...
- Re: large dataset with write vs read clients
- Re: Slow count(*) again...
- Re: large dataset with write vs read clients
- Re: DB slow down after table partition
- DB slow down after table partition
- Re: Slow count(*) again...
- Db slow down after table partition
- Re: large dataset with write vs read clients
- Re: Slow count(*) again...
- Re: Slow count(*) again...
- Re: large dataset with write vs read clients
- Re: large dataset with write vs read clients
- Re: Slow count(*) again...
- Re: Slow count(*) again...
- Re: Slow count(*) again...
- Re: Slow count(*) again...
- Re: Slow count(*) again...
- Re: Slow count(*) again...
- Slow count(*) again...
- Re: large dataset with write vs read clients
- Re: large dataset with write vs read clients
- Re: BBU Cache vs. spindles
- Re: Runtime dependency from size of a bytea field
- From: Sander, Ingo (NSN - DE/Munich)
- BBU Cache vs. spindles
- Re: large dataset with write vs read clients
- Re: Odd behaviour with redundant CREATE statement
- Re: large dataset with write vs read clients
- Re: Odd behaviour with redundant CREATE statement
- Re: [HACKERS] MIT benchmarks pgsql multicore (up to 48)performance
- Re: large dataset with write vs read clients
[Index of Archives]
[Postgresql General]
[Postgresql PHP]
[PHP Home]
[PHP on Windows]
[Yosemite]