Re: Performance figures from DbMail list

From: Erik Jones <erik(at)myemma(dot)com>
To: Scott Marlowe <smarlowe(at)g2switchworks(dot)com>
Cc: Mikael Carneholm <Mikael(dot)Carneholm(at)WirelessCar(dot)com>, "Matthew T(dot) O'Connor" <matthew(at)tocr(dot)com>, David Goodenough <david(dot)goodenough(at)btconnect(dot)com>, pgsql general <pgsql-general(at)postgresql(dot)org>
Subject: Re: Performance figures from DbMail list
Date: 2006-12-08 22:08:07
Message-ID: 4579E247.7090006@myemma.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-general

Scott Marlowe wrote:
> On Fri, 2006-12-08 at 15:44, Erik Jones wrote:
>
>> Scott Marlowe wrote:
>>
>>> On Fri, 2006-12-08 at 15:04, Mikael Carneholm wrote:
>>>
>>>
>>>> This link adds to the joy...
>>>>
>>>> http://forums.mysql.com/read.php?25,93181,93181
>>>>
>>>> So the most popular free "database" in the world is a lousy performing
>>>> product that accepts 'gabba gabba hey' as a valid timestamp. Someone
>>>> please, give me a reason not to get cynical...
>>>>
>>>>
>>> Oh man, that poor guy. He's got 4 or 5 machines in a cluster, and he's
>>> still not catching up to the one machine postgresql server.
>>>
>>> And he's switching because he wants better reliability?
>>>
>>> Guess he's never heard of pgpool, slony, mammoth replicator, cjdbc, or a
>>> half dozen other ways to get high reliability with postgresql.
>>>
>>> I wonder what version of postgresql he was testing.
>>>
>>>
>> Please, remove pgpool from your list of "reliable" postgresql tools.
>> It's decent, but child procs tend to go zombie from time to time.
>>
>
> No, I don't think I will. I've used it and tested it quite thoroughly,
> and have never had that happen. Bad hardware on your end maybe? Or an
> older version, or a bad compiler?
>
> I've found it to be very stable and reliable. If you've got a
> reproduceable test case I'm sure Tatsuo (sp) would love to see it.
>
pgpool -h reports v. 3.1. Note that this is pgpool-I and that the
release notes for the version we have say that an issue with procs dying
was fixed -- while it is certainly much better than it was in version
previous to 3.1, we have seen it happen on occasion. Test case? Hah.
This tends to happen during off hours on our high-load web servers so
the best we can do is keep an eye on things and restart when we catch
it. I see that pgpool-II has been released and since been integrated
with heartbeat which definitely sounds promising. I'm going to show it
to our deciders...

--
erik jones <erik(at)myemma(dot)com>
software development
emma(r)

In response to

Responses

Browse pgsql-general by date

  From Date Subject
Next Message Glen Parker 2006-12-08 22:12:18 Re: Marking indexes out of date (WAS: loading data, creating
Previous Message Martijn van Oosterhout 2006-12-08 22:04:51 Re: Marking indexes out of date (WAS: loading data, creating indexes, clustering, vacuum) feature request?