> 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
not-clustered, so it is "random" for descending 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 wrote:
> Kevin Traster writes:
>> The query plan a
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 = 1
On Wed, Jan 28, 2009 at 11:37 PM, Scott Marlowe wrote:
> On Thu, Jan 29, 2009 at 12:01 AM, Kevin Traster wrote:
> > 2 questions:
> >
> > 1) Different costs for same actions. Doing an explain on 2 nearly
> identical
> > queries both involving the same Index s
On Wed, Jan 28, 2009 at 11:37 PM, Scott Marlowe wrote:
> On Thu, Jan 29, 2009 at 12:01 AM, Kevin Traster wrote:
> > 2 questions:
> >
> > 1) Different costs for same actions. Doing an explain on 2 nearly
> identical
> > queries both involving the same Index s
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
sa
