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 around? Or else rewrite the
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. T
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
> (
>
bricklen writes:
> Perhaps someone else will have some other ideas of what could be useful
> here.
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.pro
On Sat, Mar 22, 2014 at 8:37 PM, Erik van Zijst wrote:
> On Sat, Mar 22, 2014 at 3:56 PM, bricklen 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
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 planner.
>
> How about encaps
On Sat, Mar 22, 2014 at 3:27 PM, Erik van Zijst wrote:
> Yes, that works (it does at least on my small test database).
>
> However, these queries are generated by a parser that translates
> complex parse trees from a higher level DSL that doesn't lend itself
> well to logically isolating the crypt
Yes, that works (it does at least on my small test database).
However, these queries are generated by a parser that translates
complex parse trees from a higher level DSL that doesn't lend itself
well to logically isolating the crypt checks from the remaining
conditions, as password checks might b
On Fri, Mar 21, 2014 at 5:59 PM, Erik van Zijst wrote:
> 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
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
10 matches
Mail list logo
