Re: Perl/DBI vs Native

From: Craig Ringer <craig(at)postnewspapers(dot)com(dot)au>
To: valiouk(at)yahoo(dot)co(dot)uk
Cc: psql performance <pgsql-performance(at)postgresql(dot)org>
Subject: Re: Perl/DBI vs Native
Date: 2008-07-21 13:49:18
Message-ID: 488493DE.4000806@postnewspapers.com.au
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-performance

Valentin Bogdanov wrote:
> Hi,
>
> I have ran quite a few tests comparing how long a query takes to execute from Perl/DBI as compared to psql/pqlib. No matter how many times I run the test the results were always the same.
>
> I run a SELECT all on a fairly big table and enabled the log_min_duration_statement option. With psql postgres consistently logs half a second while the exact same query executed with Perl/DBI takes again consistently 2 seconds.
>
> If I were timing the applications I would have been too much surprised by these results, obviously, processing with Perl would be slower than a native application. But it's the postmaster that gives these results. Could it be because the DBI module is slower at assimilating the data?
>
> Any light on the subject would be greatly appreciated.

Random guess: Perl's DBI is using parameterized prepared statements,
preventing the optimizer from using its knowledge about common values in
the table to decide whether or not index use is appropriate. When you're
writing the query in psql, you're not using prepared statements so the
optimizer can be cleverer.

Try comparing:

SELECT statement

to

PREPARE test(params) AS statement;
EXECUTE test(params);

eg:

SELECT x + 44 FROM t;

vs:

PREPARE test(int) AS x + $1 FROM t;
EXECUTE test(44);

Use EXPLAIN ANALYZE to better understand the changes in the query plan.

--
Craig Ringer

In response to

Browse pgsql-performance by date

  From Date Subject
Next Message Craig Ringer 2008-07-21 13:53:56 Re: Less rows -> better performance?
Previous Message Richard Huxton 2008-07-21 12:11:02 Re: Less rows -> better performance?