[GRASS5] Re: Feature-Request: Prompt for PostGIS-connection

[Martin Pokorny]

On Fri, 7 Nov 2003, Radim Blazek wrote:
>> I plan on doing more testing, but I need some advice, too (I
>> haven't done much with GRASS programming before). One tactic I use
>> to speed up reading is to buffer the results of a single query that
>> encompasses many features at a time. However, I need to vary the
>> size of the buffer depending on whether access is largely
>> sequential (such as when the features are first imported) or random
>> (such as when building topology). My approach appears to require
>> two, somewhat global modifications: 1) an abstract buffer size (or
>> "access pattern") setting function for all db types, and 2) use of
>> this function in several modules, such as v.in.ogr and v.clean. One
>> possibility is to set the default buffer size assuming a random
>> access pattern (i.e, small), and explicitly set the larger buffer
>> only in the v.in.* modules, but there are others. I don't have a
>> good picture of the access patterns yet, so it's hard for me to
>> decide. Ideas, clues or hints, anyone?
> 
> It would be nice to compare also PostGIS contra native, 
> perferably over the network for both. I think that it is better 
> to do benchmarks without attributes (v.in.ogr -t)

I agree, but my feeling is that native is still significantly faster.
Testing over the network is a problem for me.

> What is your 'buffer'? Is it sequence of queries executed 
> as one transaction? 
> I think, that almost everything may be done as one transaction, 
> e.g. whole v.in.ogr.

I figured out yesterday that the buffer issue was a red herring. That
technique really contributes very little to the speedup. Transactions
were already implemented, and I didn't change that.

> PL/pgSQL is something what I want to avoid. PL/pgSQL means that
> another step must be done before GRASS can be used with PostGIS. 
> What I realy worry about is, that once we use PL/pgSQL functions, it
> must be compatible for ever.

Concerning the additional steps being required, PL/pgSQL is already a
part of PostGIS, and the additional functions could be put into the
pg.postgisdb script. About your second point, I can see your
reservations; I suppose that unless PL/pgSQL proves essential, it
would be best to leave it out of GRASS.

I have not done enough testing yet with all the changes I made to know
for certain which are effective and which aren't. It's possible that
leaving out the PL/pgSQL functions won't have a big effect.

> Speed is not the only problem of PostGIS in GRASS!: 1)
> Vect_write_line, Vect_rewrite_line, Vect_delete_line are missing for
> level 2. BTW!, you can run v.in.ogr (with cleaning) or v.clean on
> PostGIS vectors? It should be impossible!

I noticed that. I realize that it would take much more work to make
PostGIS useful in GRASS.

> 2) No tests were done for simultaneous editing. There are certainly
> many potential problems in this area.

I'm well aware of that.

> Are there another reasons to use PostGIS in GRASS except multiuser
> simultaneous write access? I don't think so.

Not that I have any experience in this area, but I am under the
impression that once GRASS data is in PostGIS, it would become easier
to use from outside of GRASS (say, MapServer).

This exercise has shown me that for GRASS to better exploit PostGIS
(for example, using more efficient queries) would take considerable
effort. I'm not sure whether that would be possible without making
deeper changes in GRASS than just the *_post modules.

> Can you put your modifications somewhere on the Web?

I'll let you know when they're ready.

-- 
Martin