On Fri, Mar 21, 2014 at 5:59 PM, Erik van Zijst erik.van.zi...@gmail.comwrote:
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
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
On Sat, Mar 22, 2014 at 3:27 PM, Erik van Zijst erik.van.zi...@gmail.comwrote:
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
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 to the
On Sat, Mar 22, 2014 at 8:37 PM, Erik van Zijst erik.van.zi...@gmail.comwrote:
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