[postgis-devel] code reorganization in pgsql2shp.c

David Blasby dblasby at refractions.net
Mon Nov 17 10:17:57 PST 2003


strk wrote:
> I don't think making a row buffer will speed up things very much.
> If memory usage was a matter before, I think this is still the easiest
> way to keep it low. If we want to buffer multiple rows we should also
> compute their size to decide when to stop based on a threshold ....

I think its pretty easy - just do a "FETCH n" instead of "FETCH 1".
Just default n to something like 1000 but provide a command line switch 
to decrease it if needed.  The only time it'll be a problem is if 1000 
(or whatever they've chosen) is bigger than memory.

> If we care about speed, it might be worth using WKB or internal binary
> representation instead of parsing WKT. Internal binary representation
> will forget about endianness, so it will be safe only when both data
> and dumper run on the same machine (or endian-compatible machines).

I think pgsql2shp already uses WKB.

We should make both pgsql2shp and shp2pgsql use WKB so there isnt any 
numeric drift.  I'm currently looking at making the JDBC driver be WKB 
aware so we dont accidently move points by a wee bit.

PostGIS has internal representation to WKB "asBinary(<geom>)" and WKB to 
internal representation code "GeometryFromWKB(<wkb>)".

dave




More information about the postgis-devel mailing list