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

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 > -BEGIN PGP SIGNED MESSAGE- > Hash: SHA1 > > On 12/22/2011 12:29 AM, Havasvölgyi Ottó wrote: > > Hello, > &g

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

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/8 Bob Lunney > Otto, > > Separate the pg_xlog directory onto its own filesystem and retry your > tests. > > Bob Lunney > > ---------- > *From:* Havasvölgyi Ottó > *To:* Marti Raudsepp > *Cc:* Aidan Van Dyk ; pgsql-performance@postgr

Re: [PERFORM] Response time increases over time

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 w

Re: [PERFORM] Response time increases over time

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 > On Wed, Dec 7, 2011 at 5:13 PM, Havasvölgyi Ottó > wrote: > > > So

Re: [PERFORM] Response time increases over time

such behaviour, or what I could check or try? Thanks in advance, Otto 2011/12/7 Mario Splivalo > 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 sim

Re: [PERFORM] Response time increases over time

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 it. Anyway I am going to test 9.1 too. I will post about the results. Best reagrds, Otto 2011/12/7 Josh Berkus > On 12/6/11 4:30 PM, Havasvölgyi Ottó wr

[PERFORM] Response time increases over time

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 a

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

Thanks, it's a very good idea! Otto 2009/2/17 Kevin Grittner > >>> Havasvölgyi Ottó wrote: > > > WHERE (id1>12 or id1=12 and id2>=34) > > and (id1<56 or id1=56 and id2<=78) > > As others have pointed out, if you are using 8.2 or later, you s

[PERFORM] Query composite index range in an efficient way

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 th

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

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: Fr

Re: [PERFORM] Why hash join instead of nested loop?

Rhett, Please post the explain analyze for both queries. From that we can see the predicted and the actual costs of them. Regards, Otto - Original Message - From: "Rhett Garber" <[EMAIL PROTECTED]> To: Sent: Friday, August 05, 2005 8:35 PM Subject: [PERFORM] Why hash join instead