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
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 |