Re: Normal case or bad query plan?

Hi Kris,

>I believe the problem is that pg's lack of cross-column statistics is
>producing the poor number of rows estimate. The number of rows mataching

I got your point now. I had not understood it last night but it makes really
sense.

>which is roughtly 10% of the table. I imagine the query planner
>believes that the other condition alone will match the other 90% of the

>table. The problem is that it doesn't know that these two ranges'
>intersection is actually tiny. The planner assumes a complete or nearly
>complete overlap so it thinks it will need to fetch 10% of the rows from

Yep, because it performs those checks separately and it gets 10% for one
check and 90% for the other.

As Tom says, I should somehow make PostgreSQL see my data as a single entity
in order to perform a real range check. I will study some way to obtain
it.

However, I got better results by specifying the grane of the statistics
through "ALTER TABLE ... SET STATISTICS".

FYI I set it to 1000 (the maximum) and I reduced the query's estimated time
by the 90% (from 40000ms to 4000ms) although much slower than the index
scan (200ms).

I will play a bit with data types as Tom suggested.

For now, thanks anyone who tried and helped me.

Ciao,
-Gabriele