On Thu, May 12, 2005 at 08:54:48PM +0200, Manfred Koizar wrote:
> On Wed, 11 May 2005 16:15:16 -0500, "Jim C. Nasby" <decibel@decibel.org>
> wrote:
> >> This is divided by the number of index columns, so the index correlation
> >> is estimated to be 0.219.
> >
> >That seems like a pretty bad assumption to make.
>
> Any assumption we make without looking at entire index tuples has to be
> bad. A new GUC variable secondary_correlation introduced by my patch at
> least gives you a chance to manually control the effects of additional
> index columns.
It seems it would be much better to gather statistics on any
multi-column indexes, but I know that's probably beyond what's
reasonable for your patch.
Also, my data (http://stats.distributed.net/~decibel) indicates that
max_io isn't high enough. Look specifically at timing2.log compared to
timing.log. Thouggh, it is possibile that this is because of having
random_page_cost set to 1.1 (if I set it much higher I can't force the
index scan because the index estimate actually exceeds the cost of the
seqscan with the disable cost added in).
> >It depends on the patches, since this is a production machine. Currently
> >it's running 7.4.*mumble*,
>
> The patch referenced in
> http://archives.postgresql.org/pgsql-hackers/2003-08/msg00931.php is
> still available. It doesn't touch too many places and should be easy to
> review. I'm using it and its predecessors in production for more than
> two years. Let me know, if the 74b1 version does not apply cleanly to
> your source tree.
Looks reasonable; I'll give it a shot on 8.0 once I have replication
happening.
--
Jim C. Nasby, Database Consultant decibel@decibel.org
Give your computer some brain candy! www.distributed.net Team #1828
Windows: "Where do you want to go today?"
Linux: "Where do you want to go tomorrow?"
FreeBSD: "Are you guys coming, or what?"