Re: [GENERAL] Catalog table which stores database level information

2017-01-07 Thread Adrian Klaver
On 01/07/2017 08:12 PM, Shrikant Bhende wrote: Hi all, I am trying to find out the catalog table which stores the information about database level changes. As we can alter the values of the parameters on database level, which are applicable to the respective database only, where can I get the in

[GENERAL] Catalog table which stores database level information

2017-01-07 Thread Shrikant Bhende
Hi all, I am trying to find out the catalog table which stores the information about database level changes. As we can alter the values of the parameters on database level, which are applicable to the respective database only, where can I get the info about the values of all parameters specified a

Re: [GENERAL] Postgres 9.6.1 big slowdown by upgrading 8.4.22

2017-01-07 Thread Tom Lane
Tomas Vondra writes: > No. now() calls GetCurrentTransactionStartTimestamp(), so it does not > call gettimeofday() and so the clock source overhead is pretty much > irrelevant. Moreover it's marked as 'stable' which makes repeated calls > unnecessary. Yeah. My own thought, in view of the larg

Re: [GENERAL] Postgres 9.6.1 big slowdown by upgrading 8.4.22

2017-01-07 Thread Tomas Vondra
On 01/08/2017 01:12 AM, Alban Hertroys wrote: On 7 Jan 2017, at 15:44, Job wrote: ... This is what it happens: Postgres 8.4.22 Medium average load 1.5/2.0 Further queries respond very quickly Postgres 9.6.1 Medium average load 18.0/20.0 !! Further queries are really very slow There is a bo

Re: [GENERAL] Postgres 9.6.1 big slowdown by upgrading 8.4.22

2017-01-07 Thread Alban Hertroys
> On 7 Jan 2017, at 15:44, Job wrote: > > Hi guys, > > First of all excuse me but i really do not explain the problem, sorry... > >>> Are you being serious? You're complaining about a "big slowdown" for a >>> query that goes from 1.5ms to 4ms? >>> What is the actual problem you're trying to s

Re: [GENERAL] join_collapse_limit = 14

2017-01-07 Thread Andreas Joseph Krogh
På lørdag 07. januar 2017 kl. 18:25:42, skrev Tom Lane mailto:t...@sss.pgh.pa.us>>: Andreas Joseph Krogh writes: > På lørdag 07. januar 2017 kl. 17:48:49, skrev Tom Lane >: >  If you've got just one problem query, it might be worth your time to take >  note of the op

Re: [GENERAL] join_collapse_limit = 14

2017-01-07 Thread Tom Lane
Andreas Joseph Krogh writes: > På lørdag 07. januar 2017 kl. 17:48:49, skrev Tom Lane >: > If you've got just one problem query, it might be worth your time to take > note of the optimal join order (as seen in EXPLAIN when a good plan is > chosen) and rearrange the q

Re: [GENERAL] join_collapse_limit = 14

2017-01-07 Thread Andreas Joseph Krogh
På lørdag 07. januar 2017 kl. 17:48:49, skrev Tom Lane mailto:t...@sss.pgh.pa.us>>: Andreas Joseph Krogh writes: > I wonder; In general, is there any downside of having join_collapse_limit = 14 > on modern hardware (32 cores, 64GB RAM), and geqo_threshold=16 ? > I'm aware of it increasing plan

Re: [GENERAL] join_collapse_limit = 14

2017-01-07 Thread Tom Lane
Andreas Joseph Krogh writes: > I wonder; In general, is there any downside of having join_collapse_limit = > 14 > on modern hardware (32 cores, 64GB RAM), and geqo_threshold=16 ? > I'm aware of it increasing planning-time, but is this really an issue in > practice? It can be. The number of po

[GENERAL] join_collapse_limit = 14

2017-01-07 Thread Andreas Joseph Krogh
Hi all.   I have a query which takes forever and the only way I've been able to make it perform reasonably well is increasing join_collapse_limit to 14 (12 still produced lots of nest-loops). This way lots of nest-loops (which I think caused the slowness) was made into hash-joins and performance

Re: R: [GENERAL] Postgres 9.6.1 big slowdown by upgrading 8.4.22

2017-01-07 Thread Adrian Klaver
On 01/07/2017 06:44 AM, Job wrote: Hi guys, First of all excuse me but i really do not explain the problem, sorry... Are you being serious? You're complaining about a "big slowdown" for a query that goes from 1.5ms to 4ms? What is the actual problem you're trying to solve? Because I don't see

R: [GENERAL] Postgres 9.6.1 big slowdown by upgrading 8.4.22

2017-01-07 Thread Job
Hi guys, First of all excuse me but i really do not explain the problem, sorry... >>Are you being serious? You're complaining about a "big slowdown" for a query >>that goes from 1.5ms to 4ms? >>What is the actual problem you're trying to solve? Because I don't see one in >>the above. Single qu

Re: [GENERAL] Postgres 9.6.1 big slowdown by upgrading 8.4.22

2017-01-07 Thread Tomas Vondra
On 01/07/2017 04:43 AM, Venkata B Nagothi wrote: On Sat, Jan 7, 2017 at 2:56 AM, Job > wrote: __ Hi guys, really much appreciated your replies. >> You might want to include the query plans for each server W e use a function, the explain