On Mon, Mar 24, 2014 at 12:08 AM, Heikki Linnakangas
hlinnakan...@vmware.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
On Sat, Mar 22, 2014 at 11:40 PM, Tom Lane t...@sss.pgh.pa.us 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
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 brick...@gmail.com wrote:
On Fri, Mar 21, 2014 at 5:59 PM, Erik van Zijst erik.van.zi...@gmail.com
On Sat, Mar 22, 2014 at 3:56 PM, bricklen brick...@gmail.com wrote:
On Sat, Mar 22, 2014 at 3:27 PM, Erik van Zijst erik.van.zi...@gmail.com
I could nonetheless take a stab at it, but life would certainly be
easier if I could translate each component independently and leave
optimization
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
