Re: Oracle vs PostgreSQL in real life

From: "Hannu Krosing" <hannu(at)itmeedia(dot)ee>
To: "Jean-Paul ARGUDO" <jean-paul(dot)argudo(at)idealx(dot)com>, "Hannu Krosing" <hannu(at)krosing(dot)net>
Cc: <pgsql-hackers(at)postgresql(dot)org>
Subject: Re: Oracle vs PostgreSQL in real life
Date: 2002-02-28 12:46:38
Message-ID: 001901c1c055$f6a44b40$1600000a@tm.ee
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers


----- Original Message -----
From: "Jean-Paul ARGUDO" <jean-paul(dot)argudo(at)idealx(dot)com>
>
> it seems that on every commit, the cursor is closed... and re-opened with
new
> variables'values

I think that currently the only way to reuse query plans would be migrating
some
of your logic to backend and using SPI prepared statements.

> btw, as many asked me, queries are VERY simple, there is only a few
queries.
> Each query works on one table at a time. no joins for example. Only
massive bulk
> work with CURSORS.

Again, can't some of it be moved to backend, either using PL/PgSQL or C (or
pltcl, plperl, plpython ;)

> PS: I am currently testing vacuums between the script to pause the data
> manipulation, make a vacuum analyze and continue the treatments.

Starting with 7.2 you cand also run both analyze and simple vacuum in
parallel to the main app.

You will most likely need to run analyze once after tables are more or less
filled and then a parallel
vacuum every 5-30 sec to avoid tables growing too big. You could limit
vacuum to only those
tables that see a lot of updating (or delete/insert).

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

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Hannu Krosing 2002-02-28 13:24:15 Re: Oracle vs PostgreSQL in real life
Previous Message Alessio Bragadini 2002-02-28 10:14:32 Re: Arch (was RE: Refactoring of command.c )