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
Usage: 30kB
-> Seq Scan on job s0_m1_mjob (cost=0.00..12.00 rows=500
width=27) (actual time=0.003..0.071 rows=500 loops=1)
Total runtime: 0.818 ms
Great work,
Nick Hofstede
-Original Message-
From: Tom Lane [mailto:t...@sss.pgh.pa.us]
Sent: woensdag 3 oktober 2012 5:
Nick Hofstede writes:
> I'm struggling with a query that seems to use a suboptimal query plan.
Try it in 9.2 - this is the same type of join ordering restriction
complained of last week here:
http://archives.postgresql.org/pgsql-performance/2012-09/msg00201.php
regards, t
11 matches
Mail list logo
