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
