Skip site navigation (1) Skip section navigation (2)

about libpq-C FETCH performance issue

From: jing han <jing_han_66(at)yahoo(dot)com>
To: pgsql-interfaces(at)postgresql(dot)org
Subject: about libpq-C FETCH performance issue
Date: 2004-11-11 17:00:50
Message-ID: 20041111170050.75735.qmail@web53501.mail.yahoo.com (view raw or flat)
Thread:
Lists: pgsql-interfaces
Hello,

I'm working on a project where libpq-C is envolved. We
have several background processes keep querying
certain data from database to send out ip packets at
fast rate.

With libpq-C interface, I use 

res = PQexec(conn, "DECLARE myportal CURSOR FOR select
* from ourTables");

and then  res = PQexec(conn, "FETCH ALL in myportal");


to get the data. 

I found when our database has more and more data, res
= PQexec(conn, "FETCH ALL in myportal"); cost more and
more time, much more than 

res = PQexec(conn, "DECLARE myportal CURSOR FOR select
* from ourTables"); 

(note:ourTables can be several tables join together)

and make our sending packet rate extremely low. We get
into big problems here. 

Then I try FETCH 1 instead of FETCH ALL, no
improvement.

All the queries our background processes use was
optimized with EXPLAIN utility, these queries take
much shorter time in postgres console.

So I wonder what FETCH statement is doing: just fetch
query results from cursor or do the real query, get
the query result and give these results to us. Why it
is much slower than console sql command?

I wonder if there is other faster way ( I mean other
than FETCH ALL command) to get data from database with
libpq-C, or If you have a patch to make FETCH work
faster?

Hope to hear from you soon.


Best Regards
jing

__________________________________________________
Do You Yahoo!?
Tired of spam?  Yahoo! Mail has the best spam protection around 
http://mail.yahoo.com 

pgsql-interfaces by date

Next:From: Michael FuhrDate: 2004-11-14 01:23:41
Subject: Re: newbie libpq question...
Previous:From: jing hanDate: 2004-11-10 22:09:47
Subject: about libpq-C FETCH ALL performance issue

Privacy Policy | About PostgreSQL
Copyright © 1996-2014 The PostgreSQL Global Development Group