On Mon, Mar 24, 2014 at 12:08 AM, Heikki Linnakangas
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
On Sat, Mar 22, 2014 at 11:40 PM, Tom Lane wrote:
> Maybe I'm missing something ... but isn't the OP's query completely bogus?
>
> SELECT DISTINCT u.*
> FROM auth_user u
> JOIN bb_userprofile p ON p.user_id = u.id
> JOIN bb_identity i ON i.profile_id = p.id
> WHERE
> (
>
On Sat, Mar 22, 2014 at 3:56 PM, bricklen wrote:
> On Sat, Mar 22, 2014 at 3:27 PM, Erik van Zijst
>> I could nonetheless take a stab at it, but life would certainly be
>> easier if I could translate each component independently and leave
>> optimization to the query p
taking the WITH-AS approach.
I could nonetheless take a stab at it, but life would certainly be
easier if I could translate each component independently and leave
optimization to the query planner.
Cheers,
Erik
On Sat, Mar 22, 2014 at 1:51 PM, bricklen wrote:
>
> On Fri, Mar 21,
Hi there,
I've got a relatively simple query that contains expensive BCRYPT
functions that gets optimized in a way that causes postgres to compute
more bcrypt hashes than necessary, thereby dramatically slowing things
down.
In a certain part of our application we need to lookup users by their
use
