[PERFORM] Replication: Slony-I vs. Mammoth Replicator vs. ?

HI all, I'm trying to implement a highly-scalable, high-performance, real-time database replication system to back-up my Postgres database as data gets written. So far, Mammoth Replicator is looking pretty good but it costs $1000+ . Has anyone tried Slony-I and other replication systems? Slony

Re: [PERFORM] How to create an index for type timestamp column using rtree?

Thanks, Chris and Tom. I had read *incorrectly* that rtrees are better for <= and >= comparisons. Chris On Tue, 13 Jul 2004 14:33:48 +0800, Christopher Kings-Lynne <[EMAIL PROTECTED]> wrote: > > I'm storing some timestamps as integers (UTF) in a table and I want to > > query by <= and >= for tim

[PERFORM] How to create an index for type timestamp column using rtree?

Hi all, I'm storing some timestamps as integers (UTF) in a table and I want to query by <= and >= for times between a certain period. The table has gotten quite large and is now very slow in querying. I think it's time to create an index for the timestamp column. I tried using an rtree (for <=

Re: [PERFORM] postgres 7.4 at 100%

I see - thanks very much. I created an index for column 'oid' which I was using in a WHERE. So rule of thumb- create an index for column(s) which I use in WHERE queries. Thanks, Chis On Wed, 30 Jun 2004 15:30:52 +0800, Christopher Kings-Lynne <[EMAIL PROTECTED]> wrote: > > > > Why would I or w

Re: [PERFORM] postgres 7.4 at 100%

it's improved performance even more. Thanks, Chris On Tue, 29 Jun 2004 09:03:24 -0700, Gavin M. Roy <[EMAIL PROTECTED]> wrote: > > Is the from field nullable? If not, try "create index calllogs_from on > calllogs ( from );" and then do an explain analyze of your

Re: [PERFORM] postgres 7.4 at 100%

ok i just vacuumed it and it's taking slightly longer now to execute (only about 8 ms longer, to around 701 ms). Not using indexes for calllogs(from)... should I? The values for calllogs(from) are not unique (sorry if I'm misunderstanding your point). Thanks, Chris On Tue, 29 Jun 2004 16:21:01

Re: [PERFORM] postgres 7.4 at 100%

Wow, this simple query is taking 676.24 ms to execute! it only takes 18 ms on our other machine. This table has 150,000 rows. Is this normal? no, the machine is not running software RAID. Anyone have any ideas next as to what I should do to debug this? I'm really wondering if the Linux OS runnin

Re: [PERFORM] postgres 7.4 at 100%

Date: Sat, 26 Jun 2004 07:11:49 -0700 Subject: Re: [PERFORM] postgres 7.4 at 100% To: Doug McNaught <[EMAIL PROTECTED]> Cc: [EMAIL PROTECTED] Hello, Not to mention upping your effective_cache. Doug McNaught wrote: Chris Cheston <[EMAIL PROTECTED]> writes: shared_buffers = 40

Re: [PERFORM] postgres 7.4 at 100%

Hi Richard, Thanks so much for replying. Pls see below. Thanks in advance for any advice, Chris > People are going to need more information. Are you talking about > CPU/disk IO/memory? ## CPU is at 100%. > > > My settings are default on both boxes I think. > > Doubtful - PG crawls with the de

[PERFORM] postgres 7.4 at 100%

Hi all, I was running Postgres 7.3 and it was running at about 15% with my application. On Postgres 7.4 on another box, it was running at 100%... My settings are default on both boxes I think. There are only about 20 inserts per second, which is really low. Anyone have any ideas as to something