Re: Planner estimates and cast operations ,...

From: Bruno Wolff III <bruno(at)wolff(dot)to>
To: Hans-Juergen Schoenig <postgres(at)cybertec(dot)at>
Cc: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>, pgsql-hackers <pgsql-hackers(at)postgresql(dot)org>
Subject: Re: Planner estimates and cast operations ,...
Date: 2006-09-04 18:10:48
Message-ID: 20060904181048.GA26868@wolff.to
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

On Mon, Sep 04, 2006 at 19:09:16 +0200,
Hans-Juergen Schoenig <postgres(at)cybertec(dot)at> wrote:
>
> setting work_mem to 2gb does not help here ;)
> set it to the max value on 8.0.
> this was my first try too.
> the problem is - there is no magic switch to mislead the planner a
> little without hacking the system stats (which is not what people
> should do i would say ;) ).

Did you combine that with telling it not to use sorts? I am not sure that
will really work for GROUP BY, but it is probably an easy test. You can
do an explain to see what it will try without actually running the query
in case it picks the poor plan again.

> my question is: is adding hooks for selectivity a feasable way of
> dealing with things like that?

I think the expectation is that you create a functional index and that's
how you would tell the system to keep stats for particular functions. I
don't think data on the most common values are kept now for functional
indexes, but the index itself will still have clues about the data.

In response to

Browse pgsql-hackers by date

  From Date Subject
Next Message Tom Lane 2006-09-04 18:13:53 Re: [PATCHES] Contrib module to examine client
Previous Message Bruce Momjian 2006-09-04 18:07:40 Re: [PATCHES] Contrib module to examine client