Re: Survey results on Oracle/M$NT4 to PG72/RH72 migration

From: Hannu Krosing <hannu(at)tm(dot)ee>
To: Jean-Paul ARGUDO <jean-paul(dot)argudo(at)idealx(dot)com>
Cc: Zeugswetter Andreas SB SD <ZeugswetterA(at)spardat(dot)at>, pgsql-hackers(at)postgresql(dot)org, David BARTH <dbarth(at)idealx(dot)com>, Nat MAKAREVITCH <nat(at)idealx(dot)com>, Nicolas NICLAUSSE <nicolas(dot)niclausse(at)idealx(dot)com>, Sébastien DINOT <sebastien(dot)dinot(at)idealx(dot)com>
Subject: Re: Survey results on Oracle/M$NT4 to PG72/RH72 migration
Date: 2002-03-14 13:53:57
Message-ID: 1016114042.2308.7.camel@taru.tm.ee
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

On Thu, 2002-03-14 at 11:20, Jean-Paul ARGUDO wrote:
> > > Unless you need to run concurrent vacuums,
>
> Forgot to say too that de x3 ratio is based only on batch mode. Daemon
> mode is as faster as Oracle (wow!).
>
> Forgot to say too that in batch mode we launch concurrent vacuum analyze
> on the 2 tables constantly accessed (update/inserts only : updating
> total sale by sector/ sub-sector/ sub-sub-sector, etc.. the total sales
> has a tree structure then).
>
> The vacuum analyze on those 2 tables has a sleep of 10 s, in a
> while [ 1 ] loop in a .sh

If the general distribution of values does not drastically change in
these tables then you can save some time by running just VACUUM, not
VACUUM ANALYZE.

VACUUM does all the old tuple removing work

VACUUM ANALYZE does that + also gathers statistics which make it slower.

> > I ran some tests based on their earlier description and concurrent
> > vacuums (the new, non-locking ones) are a must, best run every few
> > seconds, as without them the ratio of dead/live tuples will be huge and
> > that will bog down the whole process.
>
> Yes, concurrent vaccums is really *GREAT* without it, the batch work is
> going slower and slower with time. Concurrent vaccum allows constant
> performances.
>
> > I also suspect (from reading their description) that the main problem of
> > parsing/optimising each and every similar query will remain even if they
> > do run in one transaction.
>
> Exactly.
>
> To answer a question in this thread: the batch has really basic SQL
> statments! CURSORS are really simple too, based on 1 to 2 "bind
> variables" that unfortunately are not processed the same way has Oracle.
> :-(

can you give me a small made-up example and then tell me what
performance you get on Oracle/NT and what on PostgreSQL/Linux ?

I'd like to try to move cursor -> backend proc and see

1) if it is big enough gain to warrant further work

2) if it can be done automatically, either by preprocessing ECPG or just
changing it

--------------
Hannu

In response to

Browse pgsql-hackers by date

  From Date Subject
Next Message Jean-Paul ARGUDO 2002-03-14 13:57:10 Re: 'Following' the Primary key
Previous Message Vince Vielhaber 2002-03-14 13:29:27 Re: insert statements