Re: Multi - table statistics

From: decibel <decibel(at)decibel(dot)org>
To: Scara Maccai <m_lists(at)yahoo(dot)it>
Cc: pgsql-general <pgsql-general(at)postgresql(dot)org>
Subject: Re: Multi - table statistics
Date: 2009-07-10 03:01:24
Message-ID: B5574269-B167-4690-A742-000F24BE3E46@decibel.org
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-general

On Jul 1, 2009, at 4:15 AM, Scara Maccai wrote:
> I query is using Index scan instead of Bitmap Index Scan because it
> "thinks" that the number of rows returned will be low (12). In
> fact, the number of rows returned is 120.
>
> This happens because there are some WHERE conditions that check
> cross-tables values (something like taba.col1 < tabb.col2) . Since
> Postgresql doesn't know (I guess) anything about cross-table values
> statistics, how are the "rows" values calculated?

Are you doing this as a JOIN or a subquery? That could make a
difference. Also, non-equality predicates (ie: <) are hard to
estimate for.

> Is there any way I can force the planner to use bitmap index scan?

I would try pulling the explicit values you need into a temp table,
analyze that, and then join. The planner will then know exactly how
many rows it's dealing with. But keep in mind that it doesn't
actually look at the values it will be getting, so if you have a
skewed distribution of values in the join column in the larger table
you might be stuck...
--
Decibel!, aka Jim C. Nasby, Database Architect decibel(at)decibel(dot)org
Give your computer some brain candy! www.distributed.net Team #1828

In response to

Browse pgsql-general by date

  From Date Subject
Next Message decibel 2009-07-10 03:03:32 Re: cache reads vs. disk reads
Previous Message Scott Marlowe 2009-07-10 02:41:36 Re: Overhead of union versus union all