2 questions:
1) Different costs for same actions. Doing an explain on 2 nearly identical
queries both involving the same Index scan on same table has 2 widely
different costs for same Index scan 303375872.86 vs. 12576.70
2) Simple query using NOT IN (subquery)was killed after 2 hrs, using the
On Wed, Jan 28, 2009 at 11:37 PM, Scott Marlowe scott.marl...@gmail.comwrote:
On Thu, Jan 29, 2009 at 12:01 AM, Kevin Traster ke...@mffais.com wrote:
2 questions:
1) Different costs for same actions. Doing an explain on 2 nearly
identical
queries both involving the same Index scan
On Wed, Jan 28, 2009 at 11:37 PM, Scott Marlowe scott.marl...@gmail.comwrote:
On Thu, Jan 29, 2009 at 12:01 AM, Kevin Traster ke...@mffais.com wrote:
2 questions:
1) Different costs for same actions. Doing an explain on 2 nearly
identical
queries both involving the same Index scan
PostgreSQL 9.1.2 on x86_64-unknown-linux-gnu, compiled by gcc (GCC) 4.1.2
20080704 (Red Hat 4.1.2-51), 64-bit
Dedicated DB server
4GB ram
Shared_Buffers = 1 GB
Effective_cache_size = 3GB
Work_mem = 32GB
Analyze done
Queries ran multiple times, same differences/results
Default Statistics =
also.
The condition is shareschange ascending, I have an index for that
condition and the planner is using it.
What else can I look at?
On Wed, Feb 8, 2012 at 11:31 AM, Tom Lane t...@sss.pgh.pa.us wrote:
Kevin Traster ktras...@freshgrillfoods.com writes:
The query plan and estimates
This is not a problem with dead rows, but the index is not really
satisfying your query and the database has to look through an
indeterminate amount of rows until the 'limit 15' is satisfied. Yeah,
backwards scans are slower, especially for disk bound scans but you
also have to consider how
