On Dec 07 06:56, Alexander Scholz wrote:
> I SELECTed them, that's right, but I didn't FETCHed them. I thought that
> would be a difference. It's at least the way it works with MSSQL and
> ODBC/OLEDB (that's where I am coming from...)
IMHO, you can reach to a similar functionaly with using async
Hi Andreas,
The same question was yesterday on [pgsql-de-allgemein] ;-)
Yes - I just found it. :-) But I don't know whether it is really the
same prob.
You have selected _ALL_ records, you got all records. Thats the point.
I SELECTed them, that's right, but I didn't FETCHed them. I thought t
On Dec 07 06:36, Alexander Scholz wrote:
> sorry for probably asking such a stupid question, but we are using a
> PQexec(). Where should I specify that cursor declaration?
Just like as you're querying with pgAdmin:
PQexec(conn, "BEGIN");
PQexec(conn, "DECLARE \"test\" CURSOR FOR SELECT * FROM \"
Hi Scott,
try
declare cursor xyz as select ...
fetch 100;
and see how that works.
sorry for probably asking such a stupid question, but we are using a
PQexec(). Where should I specify that cursor declaration?
BTW: When executing
BEGIN WORK;
DECLARE "test" CURSOR FOR SELECT * FROM "TEST"
On Dec 07 06:01, Alexander Scholz wrote:
> I have a serious performance flaw, when using postgresql 8.1 (other
> versions haven't been tested) with libpq. When executing a
>
>select * from "xyz" 1)
>
> and "xyz" contains 300'000 records, it takes more than 60 seconds for
> the query just
am 07.12.2005, um 18:01:51 +0100 mailte Alexander Scholz folgendes:
> Dear NG,
>
> I have a serious performance flaw, when using postgresql 8.1 (other
> versions haven't been tested) with libpq. When executing a
>
> select * from "xyz" 1)
>
> and "xyz" contains 300'000 records, it takes
On Wed, 2005-12-07 at 11:01, Alexander Scholz wrote:
> Dear NG,
>
> I have a serious performance flaw, when using postgresql 8.1 (other
> versions haven't been tested) with libpq. When executing a
>
> select * from "xyz" 1)
>
> and "xyz" contains 300'000 records, it takes more than 60 sec
