Skip site navigation (1) Skip section navigation (2)

Re: mysql to postgresql, performance questions

From: Thom Brown <thombrown(at)gmail(dot)com>
To: Bruce Momjian <bruce(at)momjian(dot)us>
Cc: James Mansion <james(at)mansionfamily(dot)plus(dot)com>, Hannu Krosing <hannu(at)2ndquadrant(dot)com>, Yeb Havinga <yebhavinga(at)gmail(dot)com>, Greg Smith <greg(at)2ndquadrant(dot)com>, Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>, "Ross J(dot) Reedstrom" <reedstrm(at)rice(dot)edu>, pgsql-performance(at)postgresql(dot)org
Subject: Re: mysql to postgresql, performance questions
Date: 2010-06-21 18:02:11
Message-ID: AANLkTinNWo1V5gO5RLffUhgBIWofIc6csNZRPAOFyEMk@mail.gmail.com (view raw or flat)
Thread:
Lists: pgsql-performance
On 31 March 2010 15:23, Bruce Momjian <bruce(at)momjian(dot)us> wrote:
> James Mansion wrote:
>> Hannu Krosing wrote:
>> > Pulling the plug should not corrupt a postgreSQL database, unless it was
>> > using disks which lie about write caching.
>> >
>> Didn't we recently put the old wife's 'the disks lied' tale to bed in
>> favour of actually admiting that some well known filesystems and
>> saftware raid systems have had trouble with their write barriers?
>
> I thought the issue was that many file systems do not issue the drive
> ATAPI flush command, and I suppose drives are allowed not to flush on
> write if they honor the command.
>
> --

I thought I'd attempt to renew discussion of adding PostgreSQL support
to MythTV, but here's the response:

> It is not being actively developed to my knowledge and we have
> no intention of _ever_ committing such patches. Any work you do
> *will* be wasted.
>
> It is far more likely that we'll move to embedded mysql to ease
> the administration overhead for users.

It's a surprisingly hostile response.

Thom

In response to

Responses

pgsql-performance by date

Next:From: Scott MarloweDate: 2010-06-21 18:08:05
Subject: Re: mysql to postgresql, performance questions
Previous:From: Kevin GrittnerDate: 2010-06-21 17:01:38
Subject: Re: Aggressive autovacuuming ?

Privacy Policy | About PostgreSQL
Copyright © 1996-2014 The PostgreSQL Global Development Group