Re: Large selects handled inefficiently?

From: Zlatko Calusic <zlatko(at)iskon(dot)hr>
To: "Andrew Snow" <als(at)fl(dot)net(dot)au>
Cc: "Pgsql-General(at)Postgresql(dot) Org" <pgsql-general(at)postgresql(dot)org>
Subject: Re: Large selects handled inefficiently?
Date: 2000-08-30 22:55:35
Message-ID: 87lmxexst4.fsf@atlas.iskon.hr
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-general

"Andrew Snow" <als(at)fl(dot)net(dot)au> writes:

> > I believe I can work around this problem using cursors (although I
> > don't know how well DBD::Pg copes with cursors). However, that
> > doesn't seem right -- cursors should be needed to fetch a large query
> > without having it all in memory at once...
>

Yes, I have noticed that particular bad behaviour, too.
With DBD::Pg and DBD::mysql.

At the same time, DBD::Oracle, DBD::InterBase and DBD::Sybase work as
expected. Rows are fetched with fetchrow...() functions instead of all
being sucked up into memory at the time execute() is called.

Anybody know why is that happening?

> Actually, I think thats why cursors were invented in the first place ;-) A
> cursor is what you are using if you're not fetching all the results of a
> query.
>

What bothers me is different behaviour of different DBD drivers. But,
yes, I have just subscribed to dbi-users list which is the right place
to ask that question.
--
Zlatko

In response to

Responses

Browse pgsql-general by date

  From Date Subject
Next Message mjp 2000-08-30 23:21:26 initdb Error: 'oid8'
Previous Message Jan Wieck 2000-08-30 22:14:10 Re: function