Message-ID: <488493DE.4000806@postnewspapers.com.au>
Date: Mon, 21 Jul 2008 21:49:18 +0800
From: Craig Ringer <craig@postnewspapers.com.au>
User-Agent: Thunderbird 2.0.0.14 (X11/20080505)
MIME-Version: 1.0
To: valiouk@yahoo.co.uk
Cc: psql performance <pgsql-performance@postgresql.org>
Subject: Re: Perl/DBI vs Native
References: <768129.60859.qm@web25802.mail.ukl.yahoo.com>
In-Reply-To: <768129.60859.qm@web25802.mail.ukl.yahoo.com>
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: 7bit

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