On Mon, Mar 23, 2015 at 04:25:30PM +0100, Even Rouault wrote:
> Le mercredi 18 mars 2015 18:59:28, Paul Ramsey a écrit :
> > With 1000 tables, the disparity is 300ms for the join on geometry_columns
> > and 30ms for the straight system table query.
>
> On my system, just "select * from geometry_co
Le mercredi 18 mars 2015 18:59:28, Paul Ramsey a écrit :
> With 1000 tables, the disparity is 300ms for the join on geometry_columns
> and 30ms for the straight system table query.
On my system, just "select * from geometry_columns" with 1000 tables takes ~
800 ms. Digging more into the definitio
With 1000 tables, the disparity is 300ms for the join on geometry_columns and
30ms for the straight system table query.
Still, not something that should be noticeable (really) in the context of a
batch query. I guess actually it would be twice as big, since the OGR query
runs twice (once for ge
OK, yeah, even w/o populating my database with 1000 tables, I can see the
timing difference between joining with geometry_columns, and just hitting
system tables directly
-- joined with geometry columns (14ms)
SELECT
c.relname, n.nspname, c.relkind,
g.f_geometry_column, g.type, g.coord_dimens
Yes, that’s what ‘f’ is.
It could just be that on a database with N-hundred tables the query would be
slow regardless. Something I’ll do a quick test of.
I’m writing up a few variants to go into those slots for different versions.
P
--
http://postgis.net
http://cleverelephant.ca
On March
On Wed, Mar 18, 2015 at 09:58:20AM -0700, Paul Ramsey wrote:
> There’s also a couple new relation types, ‘m’ for materialized
> views and ‘f’ for… gah! I don’t know.
I think 'f' is for foreign data tables.
It's surprising that joining a view on catalogue tables considerably
slows down. Shouldn'
On March 18, 2015 at 9:53:58 AM, Even Rouault (even.roua...@spatialys.com)
wrote:
>
> It certainly is. I think the performance issue appeared with PostGIS 2.0 when
> geometry_columns has become a view.
>
> > Probably either the query should just use the
> > system tables alone, and take adv
Hi Paul,
> We noticed that in databases with lots of tables, OGR throws some pretty
> crazy SQL at the database, and things get slow and the source of the problem
> seems to be here:
>
>
http://trac.osgeo.org/gdal/browser/trunk/gdal/ogr/ogrsf_frmts/pg/ogrpgdatasource.cpp#L851
>
> Which in addition
We noticed that in databases with lots of tables, OGR throws some pretty crazy
SQL at the database, and things get slow and the source of the problem seems to
be here:
http://trac.osgeo.org/gdal/browser/trunk/gdal/ogr/ogrsf_frmts/pg/ogrpgdatasource.cpp#L851
Which in addition to being a big quer
