Re: [PERFORM] Beowulf Cluster & Postgresql?
You might want to take a look at Matt Dillon's Backplane database. It is designed to work in a multi-node environment : http://www.backplane.com/ regards Mark joe wrote: Hi all, I was wondering if part or all of Postgres would be able to take advantage of a beowulf cluster to increase performance? If not then why not, and if so then how would/could it benefit from being on a cluster? Thanks for the enlightenment in advance. -Joe ---(end of broadcast)--- TIP 5: Have you checked our extensive FAQ? http://www.postgresql.org/docs/faqs/FAQ.html ---(end of broadcast)--- TIP 8: explain analyze is your friend
Re: [PERFORM] Beowulf Cluster & Postgresql?
On Wed, 2004-07-21 at 14:45, joe wrote: > Hi all, > I was wondering if part or all of Postgres would be able to take > advantage of a beowulf cluster to increase performance? If not then why > not, and if so then how would/could it benefit from being on a cluster? > > Thanks for the enlightenment in advance. That type of clustering helps with large parallel processes that are loosely interrelated or none at all. In PostgreSQL, as in most databases, all actions that change the data in the database tend to be highly interrelated, so it becomes very expensive to pass all that locking information back and forth. The very thing a cluster would be good at, lots of reads, very few writies, is the antithesis of what postgresql is built to be good at, lots of writes as well as lots of reads. Basically, clustering tends to make the database faster at reads and slower at writes. While there are clustering solutions out there, Beowulf clustering is oriented towards highly parallel CPU intensive workloads, while PostgreSQL tends to be I/O intensive, and since all the data needs to be stored in one "master" place, adding nodes doesn't usually help with making writes faster. ---(end of broadcast)--- TIP 3: if posting/reading through Usenet, please send an appropriate subscribe-nomail command to [EMAIL PROTECTED] so that your message can get through to the mailing list cleanly
[PERFORM] Beowulf Cluster & Postgresql?
Hi all, I was wondering if part or all of Postgres would be able to take advantage of a beowulf cluster to increase performance? If not then why not, and if so then how would/could it benefit from being on a cluster? Thanks for the enlightenment in advance. -Joe ---(end of broadcast)--- TIP 5: Have you checked our extensive FAQ? http://www.postgresql.org/docs/faqs/FAQ.html
Re: [PERFORM] extrem bad performance
Rod Taylor wrote: Lets start with an example. Please send us an EXPLAIN ANALYZE of a couple of the poorly performing queries. thanks for your answer. the problem was solved by using FULL(!) VACUUM. regards, Stefan ---(end of broadcast)--- TIP 5: Have you checked our extensive FAQ? http://www.postgresql.org/docs/faqs/FAQ.html
Re: [PERFORM] Odd sorting behaviour
On Wed, 2004-07-21 at 06:04, Steinar H. Gunderson wrote: > On Tue, Jul 20, 2004 at 10:18:19PM -0400, Rod Taylor wrote: > > I've taken a look and managed to cut out quite a bit of used time. > > You'll need to confirm it's the same results though (I didn't -- it is > > the same number of results (query below) > > It looks very much like the same results. Oh.. On my (slow) laptop it cut the time back significantly.. > As my server is 7.2 and not 7.4, that obviously won't help much :-) Thanks > anyway, though -- we'll upgrade eventually, and it'll help then. I see. Yeah, avoid NOT IN like a plague on 7.2. ---(end of broadcast)--- TIP 3: if posting/reading through Usenet, please send an appropriate subscribe-nomail command to [EMAIL PROTECTED] so that your message can get through to the mailing list cleanly
Re: [PERFORM] Odd sorting behaviour
On Tue, Jul 20, 2004 at 10:18:19PM -0400, Rod Taylor wrote: > I've taken a look and managed to cut out quite a bit of used time. > You'll need to confirm it's the same results though (I didn't -- it is > the same number of results (query below) It looks very much like the same results. > Secondly, I had no luck getting the hashjoin but this probably doesn't > matter. I've assumed that the number of users will climb faster than the > product set offered, and generated additional data via the below command > run 4 times: Actually, the number of users won't climb that much faster; what will probably increase is the number of opinions. > I found that by this point, the hashjoin and mergejoin have essentially > the same performance -- in otherwords, as you grow you'll want the > mergejoin eventually so I wouldn't worry about it too much. Hm, OK. > -- Plain join okay since o12.correlation <> 0 > -- eliminates any NULLs anyway. > -- Was RIGHT JOIN OK, that makes sense (although I don't really see why it should be faster). > -- Was old Left join >WHERE o3.prodid NOT IN (SELECT prodid > FROM opinions AS o4 > WHERE uid = 1355) As my server is 7.2 and not 7.4, that obviously won't help much :-) Thanks anyway, though -- we'll upgrade eventually, and it'll help then. /* Steinar */ -- Homepage: http://www.sesse.net/ ---(end of broadcast)--- TIP 5: Have you checked our extensive FAQ? http://www.postgresql.org/docs/faqs/FAQ.html
