Re: [PERFORM] Major performance problem after upgrade from 8.3 to 8.4

2010-09-15 Thread Gerhard Wiesinger
On Wed, 15 Sep 2010, Merlin Moncure wrote: On Wed, Sep 15, 2010 at 2:32 AM, Gerhard Wiesinger wrote: On Tue, 14 Sep 2010, Merlin Moncure wrote: np -- this felt particularly satisfying for some reason. btw, I think you have some more low hanging optimization fruit.  I think (although it

Re: [PERFORM] Major performance problem after upgrade from 8.3 to 8.4

2010-09-14 Thread Gerhard Wiesinger
On Tue, 14 Sep 2010, Merlin Moncure wrote: np -- this felt particularly satisfying for some reason. btw, I think you have some more low hanging optimization fruit. I think (although it would certainly have to be tested) hiding your attribute description under keyid is buying you nothing but head

Re: [PERFORM] Major performance problem after upgrade from 8.3 to 8.4

2010-09-14 Thread Gerhard Wiesinger
On Tue, 14 Sep 2010, Merlin Moncure wrote: On Tue, Sep 14, 2010 at 2:07 AM, Gerhard Wiesinger wrote: Hello Merlin, Seems to be a feasible approach. On problem which might be that when multiple rows are returned that they are not ordered in each subselect correctly. Any idea to solve that

Re: [PERFORM] Major performance problem after upgrade from 8.3 to 8.4

2010-09-13 Thread Gerhard Wiesinger
think about in detail. But thank you for the new approach and opening the mind :-) Ciao, Gerhard -- http://www.wiesinger.com/ On Mon, 13 Sep 2010, Merlin Moncure wrote: On Mon, Sep 13, 2010 at 2:39 AM, Gerhard Wiesinger wrote: Hello, Any news or ideas regarding this issue? hm. is

Re: [PERFORM] Major performance problem after upgrade from 8.3 to 8.4

2010-09-12 Thread Gerhard Wiesinger
Hello, Any news or ideas regarding this issue? Thnx. Ciao, Gerhard -- http://www.wiesinger.com/ On Sat, 4 Sep 2010, Gerhard Wiesinger wrote: On Fri, 3 Sep 2010, Tom Lane wrote: Gerhard Wiesinger writes: 8.3 query plans: http://www.wiesinger.com/tmp/pg_perf_83_new.txt 8.4 quey plans

Re: [PERFORM] Major performance problem after upgrade from 8.3 to 8.4

2010-09-03 Thread Gerhard Wiesinger
On Fri, 3 Sep 2010, Tom Lane wrote: Gerhard Wiesinger writes: 8.3 query plans: http://www.wiesinger.com/tmp/pg_perf_83_new.txt 8.4 quey plans: http://www.wiesinger.com/tmp/pg_perf_84.txt Hmm. The 8.3 plan is indeed assuming that the number of rows will stay constant as we bubble up through

Re: [PERFORM] Major performance problem after upgrade from 8.3 to 8.4

2010-09-03 Thread Gerhard Wiesinger
On Fri, 3 Sep 2010, Tom Lane wrote: Gerhard Wiesinger writes: On Fri, 3 Sep 2010, Tom Lane wrote: I think what may be happening here is that a postgres executable expects to find itself in a full installation tree, ie if it's in /someplace/bin then the timezone files are in /someplace/

Re: [PERFORM] Major performance problem after upgrade from 8.3 to 8.4

2010-09-03 Thread Gerhard Wiesinger
On Fri, 3 Sep 2010, Tom Lane wrote: Gerhard Wiesinger writes: On Fri, 3 Sep 2010, Tom Lane wrote: Doh. I hadn't looked closely at that. Probably you want /usr/share/zoneinfo --- at least that's what the Red Hat RPMs use. I tried even before I wrote to the mailinglist witho

Re: [PERFORM] Major performance problem after upgrade from 8.3 to 8.4

2010-09-03 Thread Gerhard Wiesinger
On Fri, 3 Sep 2010, Tom Lane wrote: Gerhard Wiesinger writes: On Fri, 3 Sep 2010, Tom Lane wrote: Huh. Try strace'ing the process to see what it's doing. It tries to find something in /usr/share/ ... Ok, I think from the compile time options: ./configure --with-system-tzdata=

Re: [PERFORM] Major performance problem after upgrade from 8.3 to 8.4

2010-09-03 Thread Gerhard Wiesinger
On Fri, 3 Sep 2010, Tom Lane wrote: Gerhard Wiesinger writes: On Fri, 3 Sep 2010, Tom Lane wrote: Not even in that pgstartup.log file you sent stderr to? Yes, also the redirected log file is empty. Also kernel log is empty. Huh. Try strace'ing the process to see what it's do

Re: [PERFORM] Major performance problem after upgrade from 8.3 to 8.4

2010-09-03 Thread Gerhard Wiesinger
On Fri, 3 Sep 2010, Tom Lane wrote: Not even in that pgstartup.log file you sent stderr to? I have seen cases before where Postgres couldn't log anything because of SELinux. If this is a Red Hat based system, look in the kernel log for AVC messages. If you see any, then SELinux is probably blo

Re: [PERFORM] Major performance problem after upgrade from 8.3 to 8.4

2010-09-02 Thread Gerhard Wiesinger
On Thu, 2 Sep 2010, Tom Lane wrote: Gerhard Wiesinger writes: Problem is that PostgreSQL doesn't listen and take much CPU and also disk I/O. 8.3 was shut down cleanly. Hm, you sure about that? What's in the postmaster log? BTW: Do I need other postgres user with a diff

Re: [PERFORM] Major performance problem after upgrade from 8.3 to 8.4

2010-09-02 Thread Gerhard Wiesinger
On Thu, 2 Sep 2010, Tom Lane wrote: Gerhard Wiesinger writes: Problem is that PostgreSQL doesn't listen and take much CPU and also disk I/O. 8.3 was shut down cleanly. Hm, you sure about that? What's in the postmaster log? That's the strange thing: I don't have anyth

Re: [PERFORM] Major performance problem after upgrade from 8.3 to 8.4

2010-09-01 Thread Gerhard Wiesinger
On Mon, 30 Aug 2010, Tom Lane wrote: Gerhard Wiesinger writes: BTW: I have the old data setup. /var/lib/pgsql-old. Is there a fast setup with old version on different TCP port possible to compare query plans? You'll need to reinstall the old executables. If you put the new executabl

Re: [PERFORM] Major performance problem after upgrade from 8.3 to 8.4

2010-08-30 Thread Gerhard Wiesinger
On Mon, 30 Aug 2010, Tom Lane wrote: Gerhard Wiesinger writes: I know the drawbacks of an EAV design but I don't want to discuss that. I want to discuss the major performance decrease of PostgreSQL 8.3 (performance was ok) to PostgreSQL 8.4 (performance is NOT ok). Any further ideas

Re: [PERFORM] Major performance problem after upgrade from 8.3 to 8.4

2010-08-30 Thread Gerhard Wiesinger
On Mon, 30 Aug 2010, Pavel Stehule wrote: 2010/8/30 Gerhard Wiesinger : On Mon, 30 Aug 2010, Pavel Stehule wrote: Hello 2010/8/30 Andreas Kretschmer : Gerhard Wiesinger wrote: I know that the data model is key/value pairs but it worked well in 8.3. I need this flexibility. Any ideas

Re: [PERFORM] Major performance problem after upgrade from 8.3 to 8.4

2010-08-30 Thread Gerhard Wiesinger
On Mon, 30 Aug 2010, Pavel Stehule wrote: Hello 2010/8/30 Andreas Kretschmer : Gerhard Wiesinger wrote: I know that the data model is key/value pairs but it worked well in 8.3. I need this flexibility. Any ideas? If i understand the query correctly it's a pivot-table, right?

Re: [PERFORM] Major performance problem after upgrade from 8.3 to 8.4

2010-08-30 Thread Gerhard Wiesinger
On Mon, 30 Aug 2010, Scott Marlowe wrote: On Mon, Aug 30, 2010 at 1:25 AM, Gerhard Wiesinger wrote: On Mon, 30 Aug 2010, Scott Marlowe wrote: On Mon, Aug 30, 2010 at 12:20 AM, Gerhard Wiesinger wrote: Hello, I just upgraded with pg_dump/restore from PostgreSQL 8.3.11 to 8.4.4 but I&#

Re: [PERFORM] Major performance problem after upgrade from 8.3 to 8.4

2010-08-30 Thread Gerhard Wiesinger
On Mon, 30 Aug 2010, Andreas Kretschmer wrote: Gerhard Wiesinger wrote: I know that the data model is key/value pairs but it worked well in 8.3. I need this flexibility. Any ideas? If i understand the query correctly it's a pivot-table, right? The view flattens the key/value stru

Re: [PERFORM] Major performance problem after upgrade from 8.3 to 8.4

2010-08-30 Thread Gerhard Wiesinger
On Mon, 30 Aug 2010, Scott Marlowe wrote: On Mon, Aug 30, 2010 at 12:20 AM, Gerhard Wiesinger wrote: Hello, I just upgraded with pg_dump/restore from PostgreSQL 8.3.11 to 8.4.4 but I'm having major performance problems with a query with many left joins. Problem is that costs are now

[PERFORM] Major performance problem after upgrade from 8.3 to 8.4

2010-08-29 Thread Gerhard Wiesinger
Hello, I just upgraded with pg_dump/restore from PostgreSQL 8.3.11 to 8.4.4 but I'm having major performance problems with a query with many left joins. Problem is that costs are now very, very, very high (was ok in 8.3). Analyze has been done. Indexes are of course there. -> Merge Left J

Re: [PERFORM] Calculation of unused columns

2009-10-19 Thread Gerhard Wiesinger
On Sun, 18 Oct 2009, Tom Lane wrote: Robert Haas writes: On Sun, Oct 18, 2009 at 1:59 PM, Jeff Janes wrote: Even if country.id is a primary or unique key? Well, we currently don't have any logic for making inferences based on unique constraints. Huh? http://archives.postgresql.org/pgsql

Re: [PERFORM] Best suiting OS

2009-10-04 Thread Gerhard Wiesinger
On Sun, 4 Oct 2009, Mark Mielke wrote: On 10/04/2009 01:55 PM, Devrim GÜNDÜZ wrote: On Sun, 2009-10-04 at 10:05 -0400, Mark Mielke wrote: So any comparisons between operating system *distributions* should be fair. Comparing a 2007 release to a 2009 release, for example, is not fair. RHEL / Ce

Re: [PERFORM] Many left outer joins with limit performance

2009-09-27 Thread Gerhard Wiesinger
http://www.wiesinger.com/ On Fri, 1 May 2009, Tom Lane wrote: Gerhard Wiesinger writes: FROM log l -- Order is relevant here LEFT OUTER JOIN key_description k1 ON k1.description = 'Raumsolltemperatur' LEFT OUTER JOIN log_details d1 ON l.id = d1.fk_id AND d1.fk_keyid = k1.keyid Surely thi

Re: [PERFORM] PG 8.3 and large shared buffer settings

2009-09-26 Thread Gerhard Wiesinger
On Sat, 26 Sep 2009, Greg Smith wrote: On Fri, 25 Sep 2009, Jeff Janes wrote: Does it do this even if the block was already in shared_buffers? Usually not. The buffer ring algorithm is used to manage pages that are read in specifically to satisfy a sequential scan (there's a slightly diffe

Re: [PERFORM] High CPU load on Postgres Server during Peak times!!!!

2009-09-25 Thread Gerhard Wiesinger
Hello Craig, Are you sure this is correct? The test program (see below) with autocommit=0 counts up when an insert is done in another session and there is no commit done. I think with each new select a new implicit transaction is done when no explicit "BEGIN" has been established. Can one

[PERFORM] Many left outer joins with limit performance

2009-05-01 Thread Gerhard Wiesinger
Hello, I want to use postgresql for data entries (every minute) from a central heating system where the timestamp is logged in a table log. For flexibility in the future for future values and for implementing several high level types I've modelled the values in a separate key/value table calle

Re: [PERFORM] [GENERAL] Fw: PostgreSQL Performance Tuning

2007-04-26 Thread Gerhard Wiesinger
Hello! I would do the following (in that order): 1.) Check for a performant application logic and application design (e.g. degree of granularity of the Java Hibernate Mapping, are there some object iterators with hundreds of objects, etc.) 2.) Check the hibernate generated queries and whether t