On 31 March 2010 15:23, Bruce Momjian br...@momjian.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
On Mon, Jun 21, 2010 at 12:02 PM, Thom Brown thombr...@gmail.com wrote:
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
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
On Wed, 2010-03-24 at 09:55 +0100, Yeb Havinga wrote:
Greg Smith wrote:
Tom Lane wrote:
So has anyone looked at porting MythTV to PG?
Periodically someone hacks together something that works, last big
effort I'm aware of was in 2006, and then it bit rots away. I'm sure
we'd
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
On Thu, Mar 25, 2010 at 2:04 PM, James Mansion
ja...@mansionfamily.plus.com 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
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
On Thu, Mar 25, 2010 at 2:29 PM, Pierre C li...@peufeu.com 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
Scott Marlowe wrote:
On Thu, Mar 25, 2010 at 2:29 PM, Pierre C li...@peufeu.com 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
Greg Smith wrote:
Tom Lane wrote:
So has anyone looked at porting MythTV to PG?
Periodically someone hacks together something that works, last big
effort I'm aware of was in 2006, and then it bit rots away. I'm sure
we'd get some user uptake on the result--MySQL corruption is one of
Yeb Havinga wrote:
Greg Smith wrote:
Tom Lane wrote:
So has anyone looked at porting MythTV to PG?
Periodically someone hacks together something that works, last big
effort I'm aware of was in 2006, and then it bit rots away. I'm sure
we'd get some user uptake on the result--MySQL
Yeb Havinga wrote:
Greg Smith wrote:
MySQL corruption is one of the top ten cause of a MythTV system
crashing.
It would be the same with PG, unless the pg cluster configuration with
mythtv would come with a properly configured WAL - I had corrupted
tables (and a personal wiki entry (the
reeds...@rice.edu (Ross J. Reedstrom) writes:
http://www.mythtv.org/wiki/PostgreSQL_Support
That's a pretty hostile presentation...
The page has had two states:
a) In 2008, someone wrote up...
After some bad experiences with MySQL (data loss by commercial power
failure, very bad
t...@sss.pgh.pa.us (Tom Lane) writes:
Ross J. Reedstrom reeds...@rice.edu writes:
On Sat, Mar 20, 2010 at 10:47:30PM -0500, Andy Colson wrote:
(I added the and trust as an after thought, because I do have one very
important 100% uptime required mysql database that is running. Its my
MythTV
On Sat, Mar 20, 2010 at 10:47:30PM -0500, Andy Colson wrote:
I guess, for me, once I started using PG and learned enough about it (all
db have their own quirks and dark corners) I was in love. It wasnt
important which db was fastest at xyz, it was which tool do I know, and
trust, that
Ross J. Reedstrom reeds...@rice.edu writes:
On Sat, Mar 20, 2010 at 10:47:30PM -0500, Andy Colson wrote:
(I added the and trust as an after thought, because I do have one very
important 100% uptime required mysql database that is running. Its my
MythTV box at home, and I have to ask
On Tue, Mar 23, 2010 at 1:22 PM, Tom Lane t...@sss.pgh.pa.us wrote:
Ross J. Reedstrom reeds...@rice.edu writes:
On Sat, Mar 20, 2010 at 10:47:30PM -0500, Andy Colson wrote:
(I added the and trust as an after thought, because I do have one very
important 100% uptime required mysql database that
Tom Lane wrote:
So has anyone looked at porting MythTV to PG?
Periodically someone hacks together something that works, last big
effort I'm aware of was in 2006, and then it bit rots away. I'm sure
we'd get some user uptake on the result--MySQL corruption is one of the
top ten cause of
On Tue, Mar 23, 2010 at 03:22:01PM -0400, Tom Lane wrote:
Ross J. Reedstrom reeds...@rice.edu writes:
Andy, you are so me! I have the exact same one-and-only-one mission
critical mysql DB, but the gatekeeper is my wife. And experience with
that instance has made me love and trust
What about InnoDB?
On Tue, Mar 23, 2010 at 4:38 PM, Greg Smith g...@2ndquadrant.com wrote:
Tom Lane wrote:
So has anyone looked at porting MythTV to PG?
Periodically someone hacks together something that works, last big effort
I'm aware of was in 2006, and then it bit rots away. I'm
On Tue, Mar 23, 2010 at 5:07 PM, Dave Crooke dcro...@gmail.com wrote:
What about InnoDB?
Depends on what parts of mysql they otherwise use. There are plenty
of features that won't work if you're using non-myisam tables, like
full text search. I tend to think any full blown (or nearly so) db is
Scott Marlowe scott.marl...@gmail.com writes:
On Tue, Mar 23, 2010 at 5:07 PM, Dave Crooke dcro...@gmail.com wrote:
What about InnoDB?
Depends on what parts of mysql they otherwise use. There are plenty
of features that won't work if you're using non-myisam tables, like
full text search. I
MyISAM is SQLLite with some threading ;-)
On Tue, Mar 23, 2010 at 6:30 PM, Scott Marlowe scott.marl...@gmail.comwrote:
On Tue, Mar 23, 2010 at 5:07 PM, Dave Crooke dcro...@gmail.com wrote:
What about InnoDB?
Depends on what parts of mysql they otherwise use. There are plenty
of features
On Tue, Mar 23, 2010 at 5:35 PM, Tom Lane t...@sss.pgh.pa.us wrote:
Scott Marlowe scott.marl...@gmail.com writes:
On Tue, Mar 23, 2010 at 5:07 PM, Dave Crooke dcro...@gmail.com wrote:
What about InnoDB?
Depends on what parts of mysql they otherwise use. There are plenty
of features that
On Sun, Mar 21, 2010 at 9:14 PM, Dave Crooke dcro...@gmail.com wrote:
Note however that Oracle offeres full transactionality and does in place row
updates. There is more than one way to do it.
There's no free lunch. If you do mvcc you have to maintain multiple
versions of the same row.
merlin
On Mon, 22 Mar 2010 12:14:51 +0100, Merlin Moncure mmonc...@gmail.com
wrote:
On Sun, Mar 21, 2010 at 9:14 PM, Dave Crooke dcro...@gmail.com wrote:
Note however that Oracle offeres full transactionality and does in
place row
updates. There is more than one way to do it.
There's no free
Absolutely ...
- for fixed size rows with a lot of small updates, Oracle wins. BTW, as of
Oracle 9 they're called UNDO tablesapces
- for lots of transactions and feely mixing transactions of all sizes, MVCC
tables (Postgres) wins
- if you just want a structured filesystem and don't have integrity
On Sat, Mar 20, 2010 at 11:47 PM, Andy Colson a...@squeakycode.net wrote:
Don't underestimate mysql. It was written to be fast. But you have to
understand the underling points: It was written to be fast at the cost of
other things... like concurrent access, and data integrity. If you want
Note however that Oracle offeres full transactionality and does in place row
updates. There is more than one way to do it.
Cheers
Dave
On Mar 21, 2010 5:43 PM, Merlin Moncure mmonc...@gmail.com wrote:
On Sat, Mar 20, 2010 at 11:47 PM, Andy Colson a...@squeakycode.net wrote:
Don't underestimate
Corin wakath...@gmail.com writes:
I'm running quite a large social community website (250k users, 16gb
database). We are currently preparing a complete relaunch and thinking about
switching from mysql 5.1.37 innodb to postgresql 8.4.2. The database server
is a dual dualcore operton 2216 with
On Fri, Mar 19, 2010 at 3:04 AM, Dimitri Fontaine
dfonta...@hi-media.com wrote:
Corin wakath...@gmail.com writes:
I'm running quite a large social community website (250k users, 16gb
database). We are currently preparing a complete relaunch and thinking about
switching from mysql 5.1.37 innodb
I also wonder why the reported runtime of 5.847 ms is so much different
to the runtime reported of my scripts (both php and ruby are almost the
same). What's the best tool to time queries in postgresql? Can this be
done from pgadmin?
I've seen differences like that. Benchmarking isn't
On Thu, Mar 18, 2010 at 10:31 AM, Corin wakath...@gmail.com wrote:
I'm running quite a large social community website (250k users, 16gb
database). We are currently preparing a complete relaunch and thinking about
switching from mysql 5.1.37 innodb to postgresql 8.4.2. The database server
is a
Hi all,
I'm running quite a large social community website (250k users, 16gb
database). We are currently preparing a complete relaunch and thinking
about switching from mysql 5.1.37 innodb to postgresql 8.4.2. The
database server is a dual dualcore operton 2216 with 12gb ram running on
I guess we need some more details about the test. Is the
connection/disconnection part of each test iteration? And how are the
databases connected (using a socked / localhost / different host)?
Anyway measuring such simple queries will tell you almost nothing about
the general app performance -
If you expect this DB to be memory resident, you should update
the cpu/disk cost parameters in postgresql.conf. There was a
post earlier today with some more reasonable starting values.
Certainly your test DB will be memory resident.
Ken
On Thu, Mar 18, 2010 at 03:31:18PM +0100, Corin wrote:
Hi
On 18 March 2010 14:31, Corin wakath...@gmail.com wrote:
Hi all,
I'm running quite a large social community website (250k users, 16gb
database). We are currently preparing a complete relaunch and thinking about
switching from mysql 5.1.37 innodb to postgresql 8.4.2. The database server
is a
time that psql or pgAdmin shows is purely the postgresql time.
Question here was about the actual application's time. Sometimes the data
transmission, fetch and processing on the app's side can take longer than
the 'postgresql' time.
Corin,
* Corin (wakath...@gmail.com) wrote:
I'm running quite a large social community website (250k users, 16gb
database). We are currently preparing a complete relaunch and thinking
about switching from mysql 5.1.37 innodb to postgresql 8.4.2. The
database server is a dual dualcore
On Thu, Mar 18, 2010 at 16:09, Stephen Frost sfr...@snowman.net wrote:
Corin,
* Corin (wakath...@gmail.com) wrote:
{QUERY PLAN=Total runtime: 5.847 ms}
This runtime is the amount of time it took for the backend to run the
query.
44.173002243042
These times are including all the time
On Thu, Mar 18, 2010 at 8:31 AM, Corin wakath...@gmail.com wrote:
Hi all,
I'm running quite a large social community website (250k users, 16gb
database). We are currently preparing a complete relaunch and thinking about
switching from mysql 5.1.37 innodb to postgresql 8.4.2. The database
On 18-3-2010 16:50 Scott Marlowe wrote:
It's different because it only takes pgsql 5 milliseconds to run the
query, and 40 seconds to transfer the data across to your applicaiton,
which THEN promptly throws it away. If you run it as
MySQL's client lib doesn't transfer over the whole thing.
Corin wrote:
Hi all,
I'm running quite a large social community website (250k users, 16gb
database). We are currently preparing a complete relaunch and thinking
about switching from mysql 5.1.37 innodb to postgresql 8.4.2. The
relaunch looks like you are nearing the end (the launch) of the
43 matches
Mail list logo
