Re: [PERFORM] Performance problems with 9.2.15

2016-07-21 Thread Johan Fredriksson
And by the way, I have also tried to upgrade to Postgresql 9.4.8 (the latest version in postgresl.org's own repository) without improvment. / Eskil -- Sent via pgsql-performance mailing list (pgsql-performance@postgresql.org) To make changes to your subscription: http://www.postgresql.o

Re: [PERFORM] Performance problems with 9.2.15

2016-07-21 Thread Johan Fredriksson
I can add that setting enable_nestloop = 0 cuts the runtime for this query down to about 4 seconds. Disabling nested loops globaly does however impacts performance of a lot of other queries. / Eskil -- Sent via pgsql-performance mailing list (pgsql-performance@postgresql.org) To make

Re: [PERFORM] less than 2 sec for response - possible?

2016-07-21 Thread Jim Nasby
On 7/19/16 9:56 AM, trafdev wrote: Will extending page to say 128K improve performance? Well, you can't go to more than 32K, but yes, it might. Even then, I think your biggest problem is that the data locality is too low. You're only grabbing ~3 rows every time you read a buffer that probabl

Re: [PERFORM] Seeing execution plan of foreign key constraint check?

2016-07-21 Thread Jim Nasby
On 7/21/16 4:59 PM, Tom Lane wrote: > As for function plans, ISTM that could be added to the PL handlers if we > wanted to (allow a function invocation to return an array of explain > outputs). Where would you put those, particularly for functions executed many times in the query? Would it incl

Re: [PERFORM] Seeing execution plan of foreign key constraint check?

2016-07-21 Thread Tom Lane
Jim Nasby writes: > On 7/19/16 3:10 PM, Tom Lane wrote: >> It's not so much that people don't care, as that it's not apparent how to >> improve this without breaking desirable system properties --- in this >> case, that functions are black boxes so far as callers are concerned. > I thought we alr

Re: [PERFORM] Seeing execution plan of foreign key constraint check?

2016-07-21 Thread Jim Nasby
On 7/19/16 3:10 PM, Tom Lane wrote: Jim Nasby writes: On 7/5/16 7:14 AM, Robert Klemme wrote: I was wondering whether there are any plans to include the plan of the FK check in EXPLAIN output. Or is there a different way to get to see all the plans of triggers as well as of the main SQL? Un

Re: [PERFORM] Performance problems with 9.2.15

2016-07-21 Thread Claudio Freire
On Thu, Jul 21, 2016 at 3:29 PM, David G. Johnston wrote: > On Thu, Jul 21, 2016 at 2:24 PM, Claudio Freire > wrote: >> >> That cross join doesn't look right. It has no join condition. > > > That is that the definition of a "CROSS JOIN"... > > David J. Well, maybe it shouldn't be. A cross join

Re: [PERFORM] Performance problems with 9.2.15

2016-07-21 Thread David G. Johnston
On Thu, Jul 21, 2016 at 2:24 PM, Claudio Freire wrote: > That cross join doesn't look right. It has no join condition. ​That is that the definition of a "CROSS JOIN"... David J.

Re: [PERFORM] Performance problems with 9.2.15

2016-07-21 Thread Claudio Freire
On Thu, Jul 21, 2016 at 11:48 AM, Johan Fredriksson wrote: > EXPLAIN ANALYZE VERBOSE SELECT DISTINCT main.* FROM Users main CROSS > JOIN ACL ACL_3 JOIN Principals Principals_1 ON ( Principals_1.id = > main.id ) JOIN CachedGroupMembers CachedGroupMembers_2 ON > ( CachedGroupMembers_2.MemberId = P

Re: [PERFORM] Performance problems with 9.2.15

2016-07-21 Thread Johan Fredriksson
> > > The rowcount estimates from 9.2 seem greatly different from the 8.4 plan. > > > Did you remember to ANALYZE all the tables after migrating? Maybe there > > > were some table-specific statistics targets that you forgot to transfer > > > over? In any case, the 9.2 plan looks like garbage-in-g