Re: Oracle vs PostgreSQL in real life : NEWS!!!

From: Jean-Paul ARGUDO <jean-paul(dot)argudo(at)IDEALX(dot)com>
To: pgsql-hackers(at)postgresql(dot)org
Cc: jean-paul(dot)argudo(at)idealx(dot)com, sdinot(at)idealx(dot)com, dbarth(at)idealx(dot)com
Subject: Re: Oracle vs PostgreSQL in real life : NEWS!!!
Date: 2002-03-01 18:44:10
Message-ID: 20020301184409.GA18646@pastis
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

> > Oracle on NT 4 : 45 minuts to go , 1200 tps (yes one thousand and two hundred
> > tps)
> >
> > Linux Red Hat 7.2 with PostgreSQL 7.2 : hours to go (statistically, 45 hours),
> > 80 tps (eighty tps).

Well... Where to start?

We work on a team of two. The other one is a C/C++ senior coder. He
mailed me a remark about datatypes on the database. Here is what he sent
me:

Our database has different datatypes, here are a count of distinct
datatypes in all tables:

197 numeric(x)
19 numeric(x,2)
2 varchar(x)
61 char(x)
36 datetime

He asked me about numeric(x) and he questioned my about how PG managed
the NUMERIC types.

I gave him a pointer on "numeric.c" in the PG srcs.

I analyzed this source and found that NUMERIC types are much most
expensive than simple INTEGER.

I really fall on the floor.. :-( I was sure with as good quality PG is,
when NUMERIC(x) columns are declared, It would be translated in INTEGER
(int2, 4 or 8, whatever...).

So, I made a pg_dump of the current database, made some perl
remplacements NUMERIC(x,0) to INTEGER.

I loaded the database and launched treatments: the results are REALLY
IMPRESIVE: here what I have:

((it is a port of Oracle/WinNT stuff to PostgreSQL/Red Hat 7.2)):

Oracle PG72 with NUMERICs PG72 with INTEGERS
--------------------------------------------------------------------------
sample
connect by
query ported 350ms 750ms 569ms
to PG
(thanks to
OpenACS code!)
--------------------------------------------------------------------------
sample "big"
query with
connect bys 3 min 30s 8 min 40s 5 min 1s
and many
sub-queries
--------------------------------------------------------------------------
Big Batch
treatment 1300 queries/s 80 queries/s 250 queries/s
queries

PRO*C to 45 min to go ~4 to 6 DAYS not yet
ECPG to go tested fully

Ratio 1:1 1:21 not yet ..
21 times slower!

--------------------------------------------------------------------------
((but this batch will be yet re-writen in pure C + libpq + SPI,
so we think we'll have better results again))

So as you see, DATA TYPES are REALLY important, as I did write on a
techdocs article ( I should have tought in this earlier )

Then?

I'll inform you of what's going on with this Oracle/winnt 2 PG/linux port :-))

And We thank you _very_ much of all the help you gave us.

Best regards and Wishes,

--
Jean-Paul ARGUDO

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Bruce Momjian 2002-03-01 18:50:03 Re: elog() patch
Previous Message Zeugswetter Andreas SB SD 2002-03-01 18:39:31 Re: elog() patch