Re: [PERFORM] Dramatic change in memory usage with version 9.1

2011-12-22 Thread Havasvölgyi Ottó
Yes, perhaps it is related to it, and the cause is the same. But they mention here a special type inet. Best regards, Otto 2011/12/22 Rafael Martinez r.m.guerr...@usit.uio.no -BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On 12/22/2011 12:29 AM, Havasvölgyi Ottó wrote: Hello, Can you

Re: [PERFORM] Dramatic change in memory usage with version 9.1

2011-12-21 Thread Havasvölgyi Ottó
Hello, Can you find some relation between the memory usage and insert statements? 9.1.2 has memory problems with inserts (even the simplest ones) on Linux and Windows too, I could produce it. Using pgbench also shows it. Some memory is not reclaimed. I could produce it also with 8.4.9 on Linux, I

Re: [PERFORM] Response time increases over time

2011-12-08 Thread Havasvölgyi Ottó
separately, or is that not so important? The strange thing is that InnoDb data and xlog are also on the same filesystem, but on a separate one (ext4) from the global one. Thanks, Otto 2011/12/8 Aidan Van Dyk ai...@highrise.ca On Wed, Dec 7, 2011 at 5:13 PM, Havasvölgyi Ottó havasvolgyi.o

Re: [PERFORM] Response time increases over time

2011-12-08 Thread Havasvölgyi Ottó
I have moved the data directory (xlog, base, global, and everything) to an ext4 file system. The result hasn't changed unfortuately. With the same load test the average response time: 80ms; from 40ms to 120 ms everything occurs. This ext4 has default settings in fstab. Have you got any other idea

Re: [PERFORM] Response time increases over time

2011-12-08 Thread Havasvölgyi Ottó
/8 Bob Lunney bob_lun...@yahoo.com Otto, Separate the pg_xlog directory onto its own filesystem and retry your tests. Bob Lunney -- *From:* Havasvölgyi Ottó havasvolgyi.o...@gmail.com *To:* Marti Raudsepp ma...@juffo.org *Cc:* Aidan Van Dyk ai...@highrise.ca

Re: [PERFORM] Response time increases over time

2011-12-07 Thread Havasvölgyi Ottó
, Havasvölgyi Ottó wrote: Is there so much difference between 8.4 and 9.1, or is this something else? Please tell me if any other info is needed. It is fairly likely that the difference you're seeing here is due to improvements made in checkpointing and other operations made between 8.4 and 9.1

Re: [PERFORM] Response time increases over time

2011-12-07 Thread Havasvölgyi Ottó
, or what I could check or try? Thanks in advance, Otto 2011/12/7 Mario Splivalo mario.spliv...@megafon.hr On 12/07/2011 09:23 AM, Havasvölgyi Ottó wrote: Thanks, Josh. The only reason I tried 8.4 first is that it was available for Debian as compiled package, so it was simpler for me to do

[PERFORM] Response time increases over time

2011-12-06 Thread Havasvölgyi Ottó
Hi all, I am running a load simulation on Debian with PostgreSQL 8.4.9 (standard Debian package). Certain number of clients do the following stepsin a transaction (read commited level) periodically (about 1.1 transaction per second / client) and concurrently: -reads a record of table Machine

[PERFORM] Query composite index range in an efficient way

2009-02-17 Thread Havasvölgyi Ottó
Hi, Let's say I have a table (tbl) with two columns: id1, id2. I have an index on (id1,id2) And I would like to query the (12;34) - (56;78) range (so it also may contain (12;58), (13;10), (40;80) etc.). With the index this can be done quite efficiently in theory, but I cannot find a way to make

Re: [PERFORM] Query composite index range in an efficient way

2009-02-17 Thread Havasvölgyi Ottó
Thanks, it's a very good idea! Otto 2009/2/17 Kevin Grittner kevin.gritt...@wicourts.gov Havasvölgyi Ottó havasvolgyi.o...@gmail.com wrote: WHERE (id112 or id1=12 and id2=34) and (id156 or id1=56 and id2=78) As others have pointed out, if you are using 8.2 or later, you should write

Re: [PERFORM] Best way to check for new data.

2005-10-28 Thread Havasvölgyi Ottó
Rodrigo, You could use LISTEN + NOTIFY with triggers. In after_insert_statement trigger you could notify a listener, the client could query it immediately. Best Regards, Otto - Original Message - From: Rodrigo Madera To: pgsql-performance@postgresql.org Sent: