Unix Technical Forum

Re: [GENERAL] more anti-postgresql FUD

This is a discussion on Re: [GENERAL] more anti-postgresql FUD within the pgsql Hackers forums, part of the PostgreSQL category; --> > -----Original Message----- > From: pgsql-general-owner@postgresql.org [mailto gsql-general- > owner@postgresql.org ] On Behalf Of Thomas Kellerer > Sent: Friday, ...


Go Back   Unix Technical Forum > Database Server Software > PostgreSQL > pgsql Hackers

FAQ Members List Calendar Search Today's Posts Mark Forums Read
  #1 (permalink)  
Old 04-12-2008, 06:18 AM
Dann Corbit
 
Posts: n/a
Default Re: [GENERAL] more anti-postgresql FUD

> -----Original Message-----
> From: pgsql-general-owner@postgresql.org [mailtogsql-general-
> owner@postgresql.org] On Behalf Of Thomas Kellerer
> Sent: Friday, October 13, 2006 2:11 PM
> To: pgsql-general@postgresql.org
> Subject: Re: [GENERAL] more anti-postgresql FUD
>
> alexei.vladishev@gmail.com wrote on 11.10.2006 16:54:
> > Do a simple test to see my point:
> >
> > 1. create table test (id int4, aaa int4, primary key (id));
> > 2. insert into test values (0,1);
> > 3. Execute "update test set aaa=1 where id=0;" in an endless loop

>
> As others have pointed out, committing the data is a vital step in when
> testing
> the performance of a relational/transactional database.
>
> What's the point of updating an infinite number of records and never
> committing
> them? Or were you running in autocommit mode?
> Of course MySQL will be faster if you don't have transactions. Just as a
> plain
> text file will be faster than MySQL.
>
> You are claiming that this test does simulate the load that your
> applications
> puts on the database server. Does this mean that you never commit data
> when
> running on MySQL?
>
> This test also proves (in my opinion) that any multi-db application when
> using
> the lowest common denominator simply won't perform equally well on all
> platforms. I'm pretty sure the same test would also show a very bad
> performance
> on an Oracle server.
> It simply ignores the basic optimization that one should do in an
> transactional
> system. (Like batching updates, committing transactions etc).
>
> Just my 0.02€
> Thomas


In a situation where a ludicroulsly high volume of update transactions is expected, probably a tool like MonetDB would be a good idea:
http://monetdb.cwi.nl/

It's basically the freely available DB correspondent to TimesTen:
http://www.oracle.com/database/timesten.html

For an in-memory database, the high speed will require heaps and gobs of RAM, but then you will be able to do transactions 10x faster than anything else can.

It might be interesting to add fragmented column tubes in RAM {like MonetDB uses} for highly transactional tables to PostgreSQL some day.

> ---------------------------(end of broadcast)---------------------------
> TIP 2: Don't 'kill -9' the postmaster


---------------------------(end of broadcast)---------------------------
TIP 2: Don't 'kill -9' the postmaster

Digg this Post!Add Post to del.icio.usBookmark Post in TechnoratiFurl this Post!
Reply With Quote
Reply


Thread Tools
Display Modes

Posting Rules
You may not post new threads
You may not post replies
You may not post attachments
You may not edit your posts

vB code is On
Smilies are On
[IMG] code is On
HTML code is Off
Trackbacks are On
Pingbacks are On
Refbacks are On
Forum Jump


All times are GMT. The time now is 05:23 PM.


Powered by vBulletin® Version 3.6.5
Copyright ©2000 - 2008, Jelsoft Enterprises Ltd.
SEO by vBSEO 3.2.0
www.UnixAdminTalk.com