Re: [PERFORM] Poor performance on very simple query ?

will ignore your desire to choose an index scan if your joining column's datatypes do not match -- Darcy Buskermolen Command Prompt, Inc. Sales/Support: +1.503.667.4564 || 24x7/Emergency: +1.800.492.2240 PostgreSQL solutions since 1997 http://www.commandprompt.com

Re: [PERFORM] Poor performance on very simple query ?

to the mailing list cleanly -- Darcy Buskermolen Command Prompt, Inc. Sales/Support: +1.503.667.4564 || 24x7/Emergency: +1.800.492.2240 PostgreSQL solutions since 1997 http://www.commandprompt.com/ ---(end of broadcast)--- TIP 4: Have you searched our

Re: [PERFORM] performance hit for replication

of insert.update/delete per second i can process. Depending on your network connection , DML volume, and the power of your backup server, the replica could be as little as 10 seconds behind the origin. A failover/switchover could occur in under 60 seconds. -- Darcy Buskermolen Wavefire

Re: [PERFORM] PostgreSQL clustering VS MySQL clustering

to continue to increase the size of the server. Personally I think your better bet might be to figure out a way to partition up your data (isn't that what google does anyway?). Stephen -- Darcy Buskermolen Wavefire Technologies Corp. ph: 250.717.0200 fx: 250.763.1759 http://www.wavefire.com

Re: [PERFORM] PostgreSQL clustering VS MySQL clustering

://people.freebsd.org/~seanc/pgmemcache/ Chris ---(end of broadcast)--- TIP 8: explain analyze is your friend -- Darcy Buskermolen Wavefire Technologies Corp. ph: 250.717.0200 fx: 250.763.1759 http://www.wavefire.com ---(end

Re: [PERFORM] PostgreSQL clustering VS MySQL clustering

On January 20, 2005 10:42 am, Mitch Pirtle wrote: On Thu, 20 Jan 2005 09:33:42 -0800, Darcy Buskermolen [EMAIL PROTECTED] wrote: Another Option to consider would be pgmemcache. that way you just build the farm out of lots of large memory, diskless boxes for keeping the whole database

Re: [PERFORM] pg replication tools?

to replicate across versions; do you require sync or will async work, etc.. Thanks again, Saranya - Do you Yahoo!? Read only the mail you want - Yahoo! Mail SpamGuard. -- Darcy Buskermolen Wavefire Technologies Corp. ph: 250.717.0200 fx: 250.763.1759 http

Re: [PERFORM] memcached and PostgreSQL

settings -- Darcy Buskermolen Wavefire Technologies Corp. ph: 250.717.0200 fx: 250.763.1759 http://www.wavefire.com ---(end of broadcast)--- TIP 5: Have you checked our extensive FAQ? http://www.postgresql.org/docs/faqs/FAQ.html

[PERFORM] Fwd: FreeBSD, PostgreSQL, semwait and sbwait!

PROTECTED] --- -- Darcy Buskermolen Wavefire Technologies Corp. ph: 250.717.0200 fx: 250.763.1759 http://www.wavefire.com ---(end of broadcast)--- TIP 9: the planner will ignore your desire to choose

Re: [PERFORM] Sun vs a P2. Interesting results.

? (And for the record - same schema, nearly same query (modified for datetime syntax) on informix runs in 3 seconds). -- Darcy Buskermolen Wavefire Technologies Corp. ph: 250.717.0200 fx: 250.763.1759 http://www.wavefire.com ---(end of broadcast)--- TIP 7

Re: [PERFORM] Sun vs a P2. Interesting results.

- same schema, nearly same query (modified for datetime syntax) on informix runs in 3 seconds). -- Darcy Buskermolen Wavefire Technologies Corp. ph: 250.717.0200 fx: 250.763.1759 http://www.wavefire.com ---(end of broadcast)--- TIP 5: Have you