Re: Normal case or bad query plan? - Mailing list pgsql-performance

From Gabriele Bartolini
Subject Re: Normal case or bad query plan?
Date
Msg-id 41536BE0000113F4@ims3d.cp.tin.it
Whole thread Raw
In response to Re: Normal case or bad query plan?  (Kris Jurka <books@ejurka.com>)
Responses Re: Normal case or bad query plan?  ("Steinar H. Gunderson" <sgunderson@bigfoot.com>)
List pgsql-performance
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


pgsql-performance by date:

Previous
From: Tom Lane
Date:
Subject: Re: execute cursor fetch
Next
From: "Steinar H. Gunderson"
Date:
Subject: Re: Normal case or bad query plan?