On Tue, Nov 1, 2011 at 07:23, Guillaume Lelarge wrote:
> [...]
>
> With 10k rows (2.3 MB) it took 3.5 seconds to retrieve data from DB and 40
> > seconds to write the file to an SATA 7200 disk with write-through cache.
> > With 100k rows (23 MB) the DB retrieve went for 35 seconds while the file
>
On Tue, 2011-11-01 at 12:39 -0400, Henry Drexler wrote:
> from enterprise db download
> 64 bit on ubuntu 10.04 lts
>
> for pgadmin 1.14.0 (sep 23 2011, rev: REL-1_14_0)
> PostgreSQL 9.1.1 on x86_64-unknown-linux-gnu, compiled by gcc (GCC) 4.1.2
> 20080704 (Red Hat 4.1.2-46), 64-bit
>
> Issue
> --
On Wed, 2011-11-02 at 09:21 +0100, boris pezzatti wrote:
> ... or (I promise this is the last guess) each row is appended to the
> file in the the loop, and on some OS's there is a problem keeping open
> the file (so that each time the file must be opened again ... adding a
> lot of extra time
On Wed, 2011-11-02 at 08:58 +0100, boris pezzatti wrote:
> Thank you Fernando for reproducing this.
> I suspect there must be some part of code in the
>
> * for each row
>* for each column
>
> loops that result inefficient only on some machines or OS's (I'm using
> Archlinux).
I'm using Fed
from enterprise db download
64 bit on ubuntu 10.04 lts
for pgadmin 1.14.0 (sep 23 2011, rev: REL-1_14_0)
PostgreSQL 9.1.1 on x86_64-unknown-linux-gnu, compiled by gcc (GCC) 4.1.2
20080704 (Red Hat 4.1.2-46), 64-bit
Issue
---
For this new version (1.14) navigate to a table > right
... or (I promise this is the last guess) each row is appended to the
file in the the loop, and on some OS's there is a problem keeping open
the file (so that each time the file must be opened again ... adding a
lot of extra time). Maybe creating all the "virtual file" in a variable
and sto
or maybe the retrieved data in RAM are somehow lazy bound ... ?
On 11/02/2011 08:58 AM, boris pezzatti wrote:
Thank you Fernando for reproducing this.
I suspect there must be some part of code in the
* for each row
* for each column
loops that result inefficient only on some machines or OS
Thank you Fernando for reproducing this.
I suspect there must be some part of code in the
* for each row
* for each column
loops that result inefficient only on some machines or OS's (I'm using
Archlinux).
In fact the extra time I and Fernando get can not only be attributed to
adding commas,