Postgres Performance Date Index
[Prev Page][Next Page]
- Re: Slow index scan on B-Tree index over timestamp field
- Re: Slow index scan on B-Tree index over timestamp field
- Re: Slow index scan on B-Tree index over timestamp field
- Re: Slow index scan on B-Tree index over timestamp field
- Re: Slow index scan on B-Tree index over timestamp field
- Re: Slow index scan on B-Tree index over timestamp field
- Slow index scan on B-Tree index over timestamp field
- Re: Hot Standby performance issue
- Re: Hot Standby performance issue
- postgresql recommendation memory
- Re: Re: Adding foreign key constraint holds exclusive lock for too long (on production database)
- Update Trigger latency utilizing the IS DISTINCT FROM syntax
- Re: Re: Adding foreign key constraint holds exclusive lock for too long (on production database)
- Re: Re: Adding foreign key constraint holds exclusive lock for too long (on production database)
- Re: Problems with hash join over nested loop
- Re: Problems with hash join over nested loop
- Re: Problems with hash join over nested loop
- Re: Adding foreign key constraint holds exclusive lock for too long (on production database)
- Re: postgres connections
- Re: Re: Adding foreign key constraint holds exclusive lock for too long (on production database)
- Re: Adding foreign key constraint holds exclusive lock for too long (on production database)
- Adding foreign key constraint holds exclusive lock for too long (on production database)
- Re: Problems with hash join over nested loop
- Re: Problems with hash join over nested loop
- Re: Problems with hash join over nested loop
- Re: Problems with hash join over nested loop
- Re: Problems with hash join over nested loop
- Re: Problems with hash join over nested loop
- Re: Problems with hash join over nested loop
- Re: Problems with hash join over nested loop
- Re: Problems with hash join over nested loop
- Problems with hash join over nested loop
- Re: Hot Standby performance issue
- Re: Hot Standby performance issue
- Re: Hot Standby performance issue
- Re: Hot Standby performance issue
- Re: Hot Standby performance issue
- Re: Hot Standby performance issue
- Re: Hot Standby performance issue
- Re: Hot Standby performance issue
- Re: Hot Standby performance issue
- Logic of lowering seq_page_cost for SSD?
- Re: Hot Standby performance issue
- Re: Hot Standby performance issue
- Re: Hot Standby performance issue
- Re: Hot Standby performance issue
- Re: Hot Standby performance issue
- Re: Hot Standby performance issue
- Re: Hot Standby performance issue
- Re: Hot Standby performance issue
- Re: Hot Standby performance issue
- Re: Hot Standby performance issue
- Re: Hot Standby performance issue
- Re: Hot Standby performance issue
- Re: Hot Standby performance issue
- Re: Hot Standby performance issue
- Re: Hot Standby performance issue
- Re: Hot Standby performance issue
- Re: Hot Standby performance issue
- Re: Hot Standby performance issue
- Re: Hot Standby performance issue
- Re: BASH script for collecting analyze-related info
- Re: Planner Conceptual Error when Joining a Subquery -- Outer Query Condition not Pulled Into Subquery
- Re: Planner Conceptual Error when Joining a Subquery -- Outer Query Condition not Pulled Into Subquery
- Re: BASH script for collecting analyze-related info
- Planner Conceptual Error when Joining a Subquery -- Outer Query Condition not Pulled Into Subquery
- Re: CPU spikes and transactions
- Re: CPU spikes and transactions
- Hot Standby performance issue
- Re: CPU spikes and transactions
- Re: CPU spikes and transactions
- Re: CPU spikes and transactions
- Re: CPU spikes and transactions
- Re: CPU spikes and transactions
- Re: CPU spikes and transactions
- Re: CPU spikes and transactions
- Re: CPU spikes and transactions
- Re: CPU spikes and transactions
- CPU spikes and transactions
- Re: limit connections pgpool
- Re: limit connections pgpool
- Re: [GENERAL] postgreSQL query via JDBC in different OS taking different running time?
- limit connections pgpool
- From: Jeison Bedoya Delgado
- Is there a Maximum number of partitions in which constraint_exclusion works?
- Re: [GENERAL] postgreSQL query via JDBC in different OS taking different running time?
- Re: [GENERAL] postgreSQL query via JDBC in different OS taking different running time?
- Re: [GENERAL] Re: [GENERAL] Help on ṕerformance
- Re: 57 minute SELECT
- Re: 57 minute SELECT
- Re: 57 minute SELECT
- Re: 57 minute SELECT
- Re: 57 minute SELECT
- Re: 57 minute SELECT
- Re: 57 minute SELECT
- Re: 57 minute SELECT
- Re: 57 minute SELECT
- Re: 57 minute SELECT
- Re: 57 minute SELECT
- Re: 57 minute SELECT
- Re: 57 minute SELECT
- Re: 57 minute SELECT
- Re: 57 minute SELECT
- Re: 57 minute SELECT
- Re: 57 minute SELECT
- 57 minute SELECT
- Re: [GENERAL] Help on ṕerformance
- From: Carlos Eduardo Sotelo Pinto
- Re: [GENERAL] Help on ṕerformance
- Re: Reseting statistics counters
- Reseting statistics counters
- From: Xenofon Papadopoulos
- Re: BASH script for collecting analyze-related info
- Re: pg_statio_all_tables columns
- From: Xenofon Papadopoulos
- Re: pg_statio_all_tables columns
- Re: pg_statio_all_tables columns
- Re: pg_statio_all_tables columns
- From: Xenofon Papadopoulos
- Re: pg_statio_all_tables columns
- pg_statio_all_tables columns
- From: Xenofon Papadopoulos
- Re: BASH script for collecting analyze-related info
- From: hubert depesz lubaczewski
- Re: Slow plan for MAX/MIN or LIMIT 1?
- Re: BASH script for collecting analyze-related info
- Re: BASH script for collecting analyze-related info
- Re: BASH script for collecting analyze-related info
- BASH script for collecting analyze-related info
- Re: Planner performance extremely affected by an hanging transaction (20-30 times)?
- Re: Planner performance extremely affected by an hanging transaction (20-30 times)?
- Re: Troubleshooting query performance issues - resolved (sort of)
- Re: Troubleshooting query performance issues - Resolved (sort of)
- Re: Cpu usage 100% on slave. s_lock problem.
- Re: Cpu usage 100% on slave. s_lock problem.
- Re: Cpu usage 100% on slave. s_lock problem.
- Re: Planner performance extremely affected by an hanging transaction (20-30 times)?
- Re: Planner performance extremely affected by an hanging transaction (20-30 times)?
- Re: Why is n_distinct always -1 for range types?
- Re: Planner performance extremely affected by an hanging transaction (20-30 times)?
- Re: Planner performance extremely affected by an hanging transaction (20-30 times)?
- Re: Why is n_distinct always -1 for range types?
- Re: Slow plan for MAX/MIN or LIMIT 1?
- Re: Slow plan for MAX/MIN or LIMIT 1?
- Re: Slow plan for MAX/MIN or LIMIT 1?
- Re: Troubleshooting query performance issues
- Re: earthdistance query performance
- Troubleshooting query performance issues
- Re: Slow plan for MAX/MIN or LIMIT 1?
- Re: Slow plan for MAX/MIN or LIMIT 1?
- earthdistance query performance
- Re: Slow plan for MAX/MIN or LIMIT 1?
- Re: Slow plan for MAX/MIN or LIMIT 1?
- Re: Planner performance extremely affected by an hanging transaction (20-30 times)?
- Re: Planner performance extremely affected by an hanging transaction (20-30 times)?
- Re: Performance bug in prepared statement binding in 9.2?
- Re: Planner performance extremely affected by an hanging transaction (20-30 times)?
- Re: Planner performance extremely affected by an hanging transaction (20-30 times)?
- From: Bartłomiej Romański
- Re: Planner performance extremely affected by an hanging transaction (20-30 times)?
- Re: Slow plan for MAX/MIN or LIMIT 1?
- Re: Slow plan for MAX/MIN or LIMIT 1?
- Bringing up new slaves faster
- Re: Planner performance extremely affected by an hanging transaction (20-30 times)?
- Re: Planner performance extremely affected by an hanging transaction (20-30 times)?
- Re: Planner performance extremely affected by an hanging transaction (20-30 times)?
- Re: Planner performance extremely affected by an hanging transaction (20-30 times)?
- Slow plan for MAX/MIN or LIMIT 1?
- Re: Planner performance extremely affected by an hanging transaction (20-30 times)?
- Re: Planner performance extremely affected by an hanging transaction (20-30 times)?
- Re: Planner performance extremely affected by an hanging transaction (20-30 times)?
- Re: Intermittent hangs with 9.2
- Re: Planner performance extremely affected by an hanging transaction (20-30 times)?
- From: Bartłomiej Romański
- Re: Planner performance extremely affected by an hanging transaction (20-30 times)?
- Planner performance extremely affected by an hanging transaction (20-30 times)?
- From: Bartłomiej Romański
- Why is n_distinct always -1 for range types?
- Re: View with and without ::text casting performs differently.
- Re: autovacuum and dead tuples
- autovacuum and dead tuples
- Re: function execute on v.9.2 slow down
- From: Александр Белинский
- Re: Planner performance extremely affected by an hanging transaction (20-30 times)?
- From: Bartłomiej Romański
- Re: Cpu usage 100% on slave. s_lock problem.
- Re: Cpu usage 100% on slave. s_lock problem.
- Re: Cpu usage 100% on slave. s_lock problem.
- Re: Cpu usage 100% on slave. s_lock problem.
- Re: Cpu usage 100% on slave. s_lock problem.
- Re: Cpu usage 100% on slave. s_lock problem.
- Re: Cpu usage 100% on slave. s_lock problem.
- Re: Cpu usage 100% on slave. s_lock problem.
- Re: function execute on v.9.2 slow down
- Re: stable and immutable functions in GROUP BY clauses.
- How to optimization database for heavy I/O from updates (software and hardware)
- From: Niels Kristian Schjødt
- Re: COPY TO and VACUUM
- Re: COPY TO and VACUUM
- Re: Extremely slow server?
- Re: Extremely slow server?
- Re: Extremely slow server?
- Re: Extremely slow server?
- Re: Extremely slow server?
- Extremely slow server?
- Re: Intermittent hangs with 9.2
- Re: Intermittent hangs with 9.2
- Re: Intermittent hangs with 9.2
- Re: How clustering for scale out works in PostgreSQL
- Re: Varchar vs foreign key vs enumerator - table and index size
- Re: Optimising views
- Re: How clustering for scale out works in PostgreSQL
- Re: Reasons for choosing one execution plan over another?
- Memory-olic query and Materialize
- Re: slow sort
- From: Maximilian Tyrtania
- Re: COPY TO and VACUUM
- Re: Performance bug in prepared statement binding in 9.2?
- Re: Performance bug in prepared statement binding in 9.2?
- Re: Performance bug in prepared statement binding in 9.2?
- Re: Reasons for choosing one execution plan over another?
- Re: Reasons for choosing one execution plan over another?
- Re: Performance bug in prepared statement binding in 9.2?
- Re: Performance bug in prepared statement binding in 9.2?
- Re: Intermittent hangs with 9.2
- Re: Intermittent hangs with 9.2
- Re: Reasons for choosing one execution plan over another?
- Re: Reasons for choosing one execution plan over another?
- Re: slow sort
- Re: slow sort
- From: Maximilian Tyrtania
- Re: slow sort
- Re: Intermittent hangs with 9.2
- Reasons for choosing one execution plan over another?
- slow sort
- From: Maximilian Tyrtania
- Re: Intermittent hangs with 9.2
- Re: Intermittent hangs with 9.2
- Intermittent hangs with 9.2
- Intermittent hangs with 9.2
- Intermittent hangs with 9.2
- Re: Intermittent hangs with 9.2
- Re: Intermittent hangs with 9.2
- Re: Intermittent hangs with 9.2
- Intermittent hangs with 9.2
- Re: Performance bug in prepared statement binding in 9.2?
- Re: Performance bug in prepared statement binding in 9.2?
- Re: Performance bug in prepared statement binding in 9.2?
- Re: Performance bug in prepared statement binding in 9.2?
- Re: Performance bug in prepared statement binding in 9.2?
- Re: Performance bug in prepared statement binding in 9.2?
- Re: Performance bug in prepared statement binding in 9.2?
- Re: Performance bug in prepared statement binding in 9.2?
- Re: Performance bug in prepared statement binding in 9.2?
- Re: Performance bug in prepared statement binding in 9.2?
- Re: Performance bug in prepared statement binding in 9.2?
- Re: Performance bug in prepared statement binding in 9.2?
- Re: Performance bug in prepared statement binding in 9.2?
- Re: Performance bug in prepared statement binding in 9.2?
- Re: RESTORE multiple DBs concurrently
- Re: View with and without ::text casting performs differently.
- Re: View with and without ::text casting performs differently.
- Re: View with and without ::text casting performs differently.
- Re: View with and without ::text casting performs differently.
- RESTORE multiple DBs concurrently
- Re: planner and having clausule
- planner and having clausule
- Re: View with and without ::text casting performs differently.
- Re: View with and without ::text casting performs differently.
- View with and without ::text casting performs differently.
- Re: [GENERAL] Can you please suggest me some links where I can learn:
- Re: COPY TO and VACUUM
- Re: COPY TO and VACUUM
- Re: COPY TO and VACUUM
- Can you please suggest me some links where I can learn:
- Re: higth performance write to disk
- Re: higth performance write to disk
- Re: higth performance write to disk
- From: Jeison Bedoya Delgado
- Re: COPY TO and VACUUM
- Re: higth performance write to disk
- higth performance write to disk
- From: Jeison Bedoya Delgado
- Re: Slow query-plan generation (fast query) PG 9.2
- Re: AMD vs Intel
- Re: AMD vs Intel
- AMD vs Intel
- Re: COPY TO and VACUUM
- Re: SQL statement over 500% slower with 9.2 compared with 9.1
- Re: COPY TO and VACUUM
- Re: Weird case of wrong index choice
- Re: Weird case of wrong index choice
- Weird case of wrong index choice
- Re: COPY TO and VACUUM
- Re: Slow query-plan generation (fast query) PG 9.2
- Re: planner parameters
- Re: Varchar vs foreign key vs enumerator - table and index size
- COPY TO and VACUUM
- Re: Slow query-plan generation (fast query) PG 9.2
- Slow query-plan generation (fast query) PG 9.2
- planner parameters
- Re: Varchar vs foreign key vs enumerator - table and index size
- Re: Varchar vs foreign key vs enumerator - table and index size
- Re: Varchar vs foreign key vs enumerator - table and index size
- Re: How clustering for scale out works in PostgreSQL
- Re: How clustering for scale out works in PostgreSQL
- Re: How clustering for scale out works in PostgreSQL
- Re: Varchar vs foreign key vs enumerator - table and index size
- Re: Varchar vs foreign key vs enumerator - table and index size
- Re: Varchar vs foreign key vs enumerator - table and index size
- Re: Varchar vs foreign key vs enumerator - table and index size
- Re: How clustering for scale out works in PostgreSQL
- Varchar vs foreign key vs enumerator - table and index size
- Re: Query plan change with multiple elements in IN clause
- Query plan change with multiple elements in IN clause
- Optimising views
- Re: How clustering for scale out works in PostgreSQL
- Re: How clustering for scale out works in PostgreSQL
- Re: How clustering for scale out works in PostgreSQL
- Re: How clustering for scale out works in PostgreSQL
- Re: How clustering for scale out works in PostgreSQL
- Re: How clustering for scale out works in PostgreSQL
- Re: How clustering for scale out works in PostgreSQL
- Re: How clustering for scale out works in PostgreSQL
- Re: How clustering for scale out works in PostgreSQL
- Re: How clustering for scale out works in PostgreSQL
- Re: How clustering for scale out works in PostgreSQL
- How clustering for scale out works in PostgreSQL
- Re: Poor OFFSET performance in PostgreSQL 9.1.6
- From: hubert depesz lubaczewski
- Re: Poor OFFSET performance in PostgreSQL 9.1.6
- Re: Poor OFFSET performance in PostgreSQL 9.1.6
- Re: Poor OFFSET performance in PostgreSQL 9.1.6
- Re: Poor OFFSET performance in PostgreSQL 9.1.6
- Poor OFFSET performance in PostgreSQL 9.1.6
- Re: SQL statement over 500% slower with 9.2 compared with 9.1
- Re: SQL statement over 500% slower with 9.2 compared with 9.1
- Re: SQL statement over 500% slower with 9.2 compared with 9.1
- Re: SQL statement over 500% slower with 9.2 compared with 9.1
- Re: Poor performance on simple queries compared to sql server express
- Re: SQL statement over 500% slower with 9.2 compared with 9.1
- Re: Cpu usage 100% on slave. s_lock problem.
- Re: Cpu usage 100% on slave. s_lock problem.
- Re: Cpu usage 100% on slave. s_lock problem.
- Re: Cpu usage 100% on slave. s_lock problem.
- Re: Cpu usage 100% on slave. s_lock problem.
- Re: Cpu usage 100% on slave. s_lock problem.
- Re: SQL statement over 500% slower with 9.2 compared with 9.1
- Cpu usage 100% on slave. s_lock problem.
- Re: Poor performance on simple queries compared to sql server express
- Re: Poor performance on simple queries compared to sql server express
- Re: Poor performance on simple queries compared to sql server express
- SQL statement over 500% slower with 9.2 compared with 9.1
- stable and immutable functions in GROUP BY clauses.
- Re: PostgreSQL 9.2.4 very slow on laptop with windows 8
- Re: Poor performance on simple queries compared to sql server express
- Poor performance on simple queries compared to sql server express
- Re: PostgreSQL 9.2.4 very slow on laptop with windows 8
- Re: PostgreSQL 9.2.4 very slow on laptop with windows 8
- PostgreSQL 9.2.4 very slow on laptop with windows 8
- Re: How to investiage slow insert problem
- From: Matheus de Oliveira
- Re: How to investiage slow insert problem
- From: Matheus de Oliveira
- Re: Function execute slow down in 9.2
- Re: How to investiage slow insert problem
- How to investiage slow insert problem
- Re: queries with DISTINCT / GROUP BY giving different plans
- Re: queries with DISTINCT / GROUP BY giving different plans
- Re: queries with DISTINCT / GROUP BY giving different plans
- Re: Can query planner prefer a JOIN over a high-cost Function?
- Can query planner prefer a JOIN over a high-cost Function?
- Re: queries with DISTINCT / GROUP BY giving different plans
- Re: queries with DISTINCT / GROUP BY giving different plans
- Re: queries with DISTINCT / GROUP BY giving different plans
- Re: DBT5 execution failed due to undefined symbol: PQescapeLiteral
- Re: How to investiage slow insert problem
- Re: How to investiage slow insert problem
- Re: How to investiage slow insert problem
- Re: How to investiage slow insert problem
- Re: How to investiage slow insert problem
- How to investiage slow insert problem
- Re: Create one query out of two
- Re: Create one query out of two
- Create one query out of two
- Re: queries with DISTINCT / GROUP BY giving different plans
- Re: queries with DISTINCT / GROUP BY giving different plans
- Re: Function execute slow down in 9.2
- From: Александр Белинский
- Re: DBT5 execution failed due to undefined symbol: PQescapeLiteral
- DBT5 execution failed due to undefined symbol: PQescapeLiteral
- Re: Need some basic information
- Re: Index on a range array
- Re: Interesting case of IMMUTABLE significantly hurting performance
- Re: queries with DISTINCT / GROUP BY giving different plans
- queries with DISTINCT / GROUP BY giving different plans
- Re: Index on a range array
- From: Daniel Cristian Cruz
- Need some basic information
- Re: Interesting case of IMMUTABLE significantly hurting performance
- Re: Interesting case of IMMUTABLE significantly hurting performance
- Re: Interesting case of IMMUTABLE significantly hurting performance
- Re: Interesting case of IMMUTABLE significantly hurting performance
- Re: Interesting case of IMMUTABLE significantly hurting performance
- Interesting case of IMMUTABLE significantly hurting performance
- Re: subselect requires offset 0 for good performance.
- Re: subselect requires offset 0 for good performance.
- Re: subselect requires offset 0 for good performance.
- Index on a range array
- From: Daniel Cristian Cruz
- Re: Function execute slow down in 9.2
- Function execute slow down in 9.2
- From: Александр Белинский
- function execute on v.9.2 slow down
- From: Александр Белинский
- Re: Efficient Correlated Update
- Re: Efficient Correlated Update
- Re: Efficient Correlated Update
- Re: Efficient Correlated Update
- Re: Efficient Correlated Update
- Re: subselect requires offset 0 for good performance.
- Re: Efficiently query for the most recent record for a given user
- Efficient Correlated Update
- Re: [PERFORM] RE: [PERFORM] Re: [PERFORM] Sub-optimal plan for a paginated query on a view with another view inside of it.
- Re: Efficiently query for the most recent record for a given user
- Re: Efficiently query for the most recent record for a given user
- Re: Efficiently query for the most recent record for a given user
- Re: Efficiently query for the most recent record for a given user
- Re: Efficiently query for the most recent record for a given user
- Re: Efficiently query for the most recent record for a given user
- Re: Efficiently query for the most recent record for a given user
- Re: Efficiently query for the most recent record for a given user
- Efficiently query for the most recent record for a given user
- Re: Better performance possible for a pathological query?
- Re: Better performance possible for a pathological query?
- Re: RE: [PERFORM] Re: [PERFORM] Sub-optimal plan for a paginated query on a view with another view inside of it.
- Re: Re: [PERFORM] Sub-optimal plan for a paginated query on a view with another view inside of it.
- Better performance possible for a pathological query?
- RE: [PERFORM] Re: [PERFORM] Sub-optimal plan for a paginated query on a view with another view inside of it.
- Re: Re: [PERFORM] Sub-optimal plan for a paginated query on a view with another view inside of it.
- Re: Re: [PERFORM] Sub-optimal plan for a paginated query on a view with another view inside of it.
- Re: Re: [PERFORM] Sub-optimal plan for a paginated query on a view with another view inside of it.
- RE: [PERFORM] Re: [PERFORM] Sub-optimal plan for a paginated query on a view with another view inside of it.
- Re: Re: [PERFORM] Sub-optimal plan for a paginated query on a view with another view inside of it.
- Re: [PERFORM] Sub-optimal plan for a paginated query on a view with another view inside of it.
- Re: ORDER BY, LIMIT and indexes
- Re: ORDER BY, LIMIT and indexes
- Re: ORDER BY, LIMIT and indexes
- Re: ORDER BY, LIMIT and indexes
- Re: ORDER BY, LIMIT and indexes
- Re: ORDER BY, LIMIT and indexes
- Re: subselect requires offset 0 for good performance.
- Re: Sub-optimal plan for a paginated query on a view with another view inside of it.
- Re: ORDER BY, LIMIT and indexes
- Re: ORDER BY, LIMIT and indexes
- Re: ORDER BY, LIMIT and indexes
- Re: ORDER BY, LIMIT and indexes
- Re: ORDER BY, LIMIT and indexes
- Re: PG performance issues related to storage I/O waits
- Re: ORDER BY, LIMIT and indexes
- Re: ORDER BY, LIMIT and indexes
- Re: ORDER BY, LIMIT and indexes
- Re: ORDER BY, LIMIT and indexes
- Re: ORDER BY, LIMIT and indexes
- ORDER BY, LIMIT and indexes
- Re: PG performance issues related to storage I/O waits
- Re: Sub-optimal plan for a paginated query on a view with another view inside of it.
- Re: PG performance issues related to storage I/O waits
- Re: subselect requires offset 0 for good performance.
- Re: Looks like merge join planning time is too big, 55 seconds
- Re: to many locks held
- Re: subselect requires offset 0 for good performance.
- Re: subselect requires offset 0 for good performance.
- Re: subselect requires offset 0 for good performance.
- Re: Looks like merge join planning time is too big, 55 seconds
- Re: subselect requires offset 0 for good performance.
- Re: Looks like merge join planning time is too big, 55 seconds
- Re: Looks like merge join planning time is too big, 55 seconds
- Re: subselect requires offset 0 for good performance.
- Re: Looks like merge join planning time is too big, 55 seconds
- Re: Looks like merge join planning time is too big, 55 seconds
- Re: Looks like merge join planning time is too big, 55 seconds
- Re: Looks like merge join planning time is too big, 55 seconds
- Sub-optimal plan for a paginated query on a view with another view inside of it.
- Re: subselect requires offset 0 for good performance.
- Re: Looks like merge join planning time is too big, 55 seconds
- Re: subselect requires offset 0 for good performance.
- Re: Looks like merge join planning time is too big, 55 seconds
- Re: subselect requires offset 0 for good performance.
- Re: Looks like merge join planning time is too big, 55 seconds
- Re: subselect requires offset 0 for good performance.
- Re: Looks like merge join planning time is too big, 55 seconds
- subselect requires offset 0 for good performance.
- Re: Performance bug in prepared statement binding in 9.2?
- Re: Looks like merge join planning time is too big, 55 seconds
- Re: Looks like merge join planning time is too big, 55 seconds
- Re: Performance bug in prepared statement binding in 9.2?
- Re: Looks like merge join planning time is too big, 55 seconds
- Re: Looks like merge join planning time is too big, 55 seconds
- Re: Looks like merge join planning time is too big, 55 seconds
- Re: Looks like merge join planning time is too big, 55 seconds
- Re: Looks like merge join planning time is too big, 55 seconds
- Re: Looks like merge join planning time is too big, 55 seconds
- Looks like merge join planning time is too big, 55 seconds
- Re: PG performance issues related to storage I/O waits
- Re: Fw: [osdldbt-general] Running DBT5 on remote database server
- Re: PG performance issues related to storage I/O waits
- PG performance issues related to storage I/O waits
- Re: to many locks held
- Re: to many locks held
- to many locks held
- Re: FTS performance issue - planner problem identified (but only partially resolved)
- Re: FTS performance issue - planner problem identified (but only partially resolved)
- Re: How is memory allocated/used by Postgresql Database connections
- Re: How is memory allocated/used by Postgresql Database connections
- Re: Fw: [osdldbt-general] Running DBT5 on remote database server
- How is memory allocated/used by Postgresql Database connections
- From: McKinzie, Alan (Alan)
- Re: Fw: [osdldbt-general] Running DBT5 on remote database server
- Fw: [osdldbt-general] Running DBT5 on remote database server
- Re: FTS performance issue - planner problem identified (but only partially resolved)
- Re: FTS performance issue - planner problem identified (but only partially resolved)
- Re: FTS performance issue - planner problem identified (but only partially resolved)
- Re: Fwd: Relatively high planner overhead on partitions?
- Fwd: Relatively high planner overhead on partitions?
- Re: FTS performance issue - planner problem identified (but only partially resolved)
- Re: How to properly index hstore tags column to faster search for keys
- FTS performance issue - planner problem identified (but only partially resolved)
- Re: PostgreSQL settings for running on an SSD drive
- Re: Re: bgwriter autotuning might be unnecessarily penalizing bursty workloads
- Re: Re: bgwriter autotuning might be unnecessarily penalizing bursty workloads
- Re: PostgreSQL settings for running on an SSD drive
- Re: bgwriter autotuning might be unnecessarily penalizing bursty workloads
- bgwriter autotuning might be unnecessarily penalizing bursty workloads
- Re: Seq Scan vs Index on Identical Tables in Two Different Databases
- Re: Seq Scan vs Index on Identical Tables in Two Different Databases
- Re: Seq Scan vs Index on Identical Tables in Two Different Databases
- Re: Seq Scan vs Index on Identical Tables in Two Different Databases
- Seq Scan vs Index on Identical Tables in Two Different Databases
- Re: Distributed transactions and asynchronous commit
- From: Xenofon Papadopoulos
- Re: Distributed transactions and asynchronous commit
- Re: Distributed transactions and asynchronous commit
- Re: Distributed transactions and asynchronous commit
- Re: Distributed transactions and asynchronous commit
- From: Xenofon Papadopoulos
- Re: Distributed transactions and asynchronous commit
- Re: Distributed transactions and asynchronous commit
- Re: Trying to eliminate union and sort
- Distributed transactions and asynchronous commit
- From: Xenofon Papadopoulos
- Re: General key issues when comparing performance between PostgreSQL and oracle
- Re: General key issues when comparing performance between PostgreSQL and oracle
- Re: General key issues when comparing performance between PostgreSQL and oracle
- General key issues when comparing performance between PostgreSQL and oracle
- Re: Hstore VS. JSON
- Re: Hstore VS. JSON
- Hstore VS. JSON
- From: Niels Kristian Schjødt
- Re: Trying to eliminate union and sort
- Thought you'd find this interesting
- Re: Trying to eliminate union and sort
- Re: how to speed up the index creation in GP?
- Re: In progress INSERT wrecks plans on table
- Re: In progress INSERT wrecks plans on table
- Re: In progress INSERT wrecks plans on table
- Re: Trying to eliminate union and sort
- Re: Trying to eliminate union and sort
- Re: Trying to eliminate union and sort
- Trying to eliminate union and sort
- how to speed up the index creation in GP?
- Re: Process in state BIND, authentication, PARSE
- Re: Performance autovaccum
- Re: Performance autovaccum
- Re: Performance autovaccum
- Re: Process in state BIND, authentication, PARSE
- Re: Process in state BIND, authentication, PARSE
- Re: Performance autovaccum
- Re: Process in state BIND, authentication, PARSE
- Re: Process in state BIND, authentication, PARSE
- Re: 8.4 to 9.2 migration performance
- Process in state BIND, authentication, PARSE
- 8.4 to 9.2 migration performance
- Performance autovaccum
- Re: How to properly index hstore tags column to faster search for keys
- Re: How to properly index hstore tags column to faster search for keys
- Re: How to properly index hstore tags column to faster search for keys
- From: Radu-Stefan Zugravu
- Re: How to properly index hstore tags column to faster search for keys
- Re: How to properly index hstore tags column to faster search for keys
- From: Radu-Stefan Zugravu
- Re: How to properly index hstore tags column to faster search for keys
- Re: How to properly index hstore tags column to faster search for keys
- From: Radu-Stefan Zugravu
- Re: How to properly index hstore tags column to faster search for keys
- How to properly index hstore tags column to faster search for keys
- From: Radu-Stefan Zugravu
- Re: Dynamic queries in stored procedure
- Re: Dynamic queries in stored procedure
- Re: Dynamic queries in stored procedure
- Dynamic queries in stored procedure
- Re: My changes in the postgresql.conf does not work
- My changes in the postgresql.conf does not work
- [OT] A flash filesystem tuning guide
- Re: Fillfactor in postgresql 9.2
- Re: Fillfactor in postgresql 9.2
- Fillfactor in postgresql 9.2
- From: Niels Kristian Schjødt
- Re: 9.2.2 - semop hanging
- Re: Partitions not Working as Expected
- Re: Partitions not Working as Expected
- Re: Partitions not Working as Expected
- Re: Partitions not Working as Expected
- Re: Partitions not Working as Expected
- Re: Partitions not Working as Expected
- Re: Partitions not Working as Expected
- Re: Partitions not Working as Expected
- Re: Partitions not Working as Expected
- Re: Partitions not Working as Expected
- Re: Partitions not Working as Expected
- Re: Partitions not Working as Expected
- Re: Partitions not Working as Expected
- Re: Partitions not Working as Expected
- Re: Partitions not Working as Expected
- Partitions not Working as Expected
- Re: incorrect row estimates for primary key join
- Re: incorrect row estimates for primary key join
- Re: Weird, bad 0.5% selectivity estimate for a column equal to itself
- Re: seqscan for 100 out of 3M rows, index present
- Re: seqscan for 100 out of 3M rows, index present
- Re: seqscan for 100 out of 3M rows, index present
- Re: seqscan for 100 out of 3M rows, index present
- Re: seqscan for 100 out of 3M rows, index present
- Re: seqscan for 100 out of 3M rows, index present
- Re: seqscan for 100 out of 3M rows, index present
- Re: seqscan for 100 out of 3M rows, index present
- Re: seqscan for 100 out of 3M rows, index present
- Re: seqscan for 100 out of 3M rows, index present
- Re: seqscan for 100 out of 3M rows, index present
- Re: seqscan for 100 out of 3M rows, index present
- Re: seqscan for 100 out of 3M rows, index present
- Re: seqscan for 100 out of 3M rows, index present
- Re: seqscan for 100 out of 3M rows, index present
- seqscan for 100 out of 3M rows, index present
- Re: Weird, bad 0.5% selectivity estimate for a column equal to itself
- Re: incorrect row estimates for primary key join
- Re: incorrect row estimates for primary key join
- Re: Weird, bad 0.5% selectivity estimate for a column equal to itself
- Re: incorrect row estimates for primary key join
- Re: incorrect row estimates for primary key join
- Re: incorrect row estimates for primary key join
- Re: incorrect row estimates for primary key join
- Re: PHP Postgres query slower then PgAdmin
- Re: on disk and in memory
- on disk and in memory
- Re: incorrect row estimates for primary key join
- Re: incorrect row estimates for primary key join
- incorrect row estimates for primary key join
- Re: PHP Postgres query slower then PgAdmin
- Re: PHP Postgres query slower then PgAdmin
- Re: PHP Postgres query slower then PgAdmin
- Re: PHP Postgres query slower then PgAdmin
- Re: Weird, bad 0.5% selectivity estimate for a column equal to itself
- Re: Weird, bad 0.5% selectivity estimate for a column equal to itself
- Re: Weird, bad 0.5% selectivity estimate for a column equal to itself
- Weird, bad 0.5% selectivity estimate for a column equal to itself
- Re: Query tuning: partitioning, DISTINCT ON, and indexing
- Re: Query tuning: partitioning, DISTINCT ON, and indexing
- Re: Query tuning: partitioning, DISTINCT ON, and indexing
- Re: Query tuning: partitioning, DISTINCT ON, and indexing
- Query tuning: partitioning, DISTINCT ON, and indexing
- Re: PostgreSQL settings for running on an SSD drive
- Re: PostgreSQL settings for running on an SSD drive
- Re: PostgreSQL settings for running on an SSD drive
- Re: PostgreSQL settings for running on an SSD drive
- PostgreSQL settings for running on an SSD drive
- Re: pg_stat_statements behavior in crash recovery
- Re: pg_stat_statements behavior in crash recovery
- pg_stat_statements behavior in crash recovery
- Re: pg_stat_statements query normalization
- Re: 9.2.2 - semop hanging
- Re: 9.2.2 - semop hanging
- Re: pg_stat_statements query normalization
- pg_stat_statements query normalization
- Re: In progress INSERT wrecks plans on table
- Re: In progress INSERT wrecks plans on table
- Re: In progress INSERT wrecks plans on table
- Re: In progress INSERT wrecks plans on table
- Re: In progress INSERT wrecks plans on table
- Re: Query performance
- Query performance
- 9.2.2 - semop hanging
- Re: URGENT issue: pg-xlog growing on master!
- From: Niels Kristian Schjødt
- Re: URGENT issue: pg-xlog growing on master!
- From: Niels Kristian Schjødt
- Re: URGENT issue: pg-xlog growing on master!
- Re: URGENT issue: pg-xlog growing on master!
- From: Niels Kristian Schjødt
- Re: URGENT issue: pg-xlog growing on master!
- From: Matheus de Oliveira
- Re: URGENT issue: pg-xlog growing on master!
- Re: URGENT issue: pg-xlog growing on master!
- Re: URGENT issue: pg-xlog growing on master!
- From: Niels Kristian Schjødt
- Re: URGENT issue: pg-xlog growing on master!
- Re: URGENT issue: pg-xlog growing on master!
- From: Niels Kristian Schjødt
[Index of Archives]
[Postgresql General]
[Postgresql PHP]
[PHP Home]
[PHP on Windows]
[Yosemite]