[postgis-users] Improving Performance
David Blasby
dblasby at refractions.net
Thu Feb 19 10:13:12 PST 2004
colin> We were wondering why a sample 200MB text file of 8
colin> million points ballooned into over a gigabyte when
Your text file is using about 26 bytes/point.
WKB representation (in posgresql) would be 29 bytes/point.
If you want, you can create this now with "CREATE TABLE myWKB AS
SELECT asBinary(the_geom), ... FROM ...". Unfortunately there isnt
much support wrapped around the WKB type at the momenet.
The current postgis implementation is about 114 bytes/point (thats
why you're seeing 5* larger size in postgresql).
By taking the redundant info (56 bytes) out of the postgis type,
it would be about 58 bytes.
redunandant info: BVOL.zmin (8 bytes), BVOL.zmax (8 bytes),
offsetX (8 bytes), offsetY (8 bytes), scale (8 bytes),
convert the bounding box to float32s (16 bytes).
** I'm not sure if its a good idea to convert the bounding box to
float32s. We might be able to remove the entire bounding box, but
I'm not sure how that would affect performance.
I'm a bit wary of using a bunch of different types for different
"geometric things" in the database. There's a high cost associated with
getting a type up and running, indexable, and convertable to and from
the GEOMETRY type. Thats why I recommended a full WKB type since it can
represent any geometry relatively efficiently. Because there already
GEOMETRY <-> WKB functions, we can add all the geometric functions to
the type automatically.
dave
More information about the postgis-users
mailing list