From: | Erik van Zijst <erik(dot)van(dot)zijst(at)gmail(dot)com> |
---|---|
To: | Heikki Linnakangas <hlinnakangas(at)vmware(dot)com> |
Cc: | "pgsql-performance(at)postgresql(dot)org list" <pgsql-performance(at)postgresql(dot)org> |
Subject: | Re: Suboptimal query plan when using expensive BCRYPT functions |
Date: | 2014-03-24 17:37:53 |
Message-ID: | CA+69USu5YD3Y_10Gmkz9C-LO-uhOdHBTUZ0LKowPaiG42RToTQ@mail.gmail.com |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-performance |
On Mon, Mar 24, 2014 at 12:08 AM, Heikki Linnakangas
<hlinnakangas(at)vmware(dot)com> wrote:
> On 03/22/2014 02:59 AM, Erik van Zijst wrote:
>>
>> Is there any way I can get postgres to perform the hash calculations
>> on the *result* of the other parts of the where clause, instead of the
>> other way around? Or else rewrite the query?
>
>
> The planner doesn't know that the crypt function is expensive. That can be
> fixed with "ALTER FUNCTION crypt(text, text) COST <high value>". Even with
> that, I'm not sure if the planner is smart enough to optimize the query the
> way you'd want, but it's worth a try.
Thanks. That's the kind of hint I was looking for.
I just gave it a go, but unfortunately it's not enough to get the
optimizer to change the plan, regardless of the cost value.
Cheers,
Erik
From | Date | Subject | |
---|---|---|---|
Next Message | Stefan Amshey | 2014-03-24 18:40:03 | Re: slow join not using index properly |
Previous Message | Matthew Spilich | 2014-03-24 14:37:57 | semaphore waits and performance stall |