Thread: How to find out programmatically whether a query on a view will use an index?

Hi,

I'm using the PostGIS spatial extension. Some of my spatial queries (like
live zooming and panning) should only be performed when the column
containing the spatial data is spatially indexed, otherwise the first query
takes almost forever and users will just kill the application out of
frustration.

I can easily find out whether a spatial column in a table is spatially
indexed, using pg_class, pg_index, and pg_opclass. But this doesn't work for
views. I can't find out whether a column in a view, is just an 'exact copy'
of a column in a table (indicating that there's a chance that an index on
the table column could be used for a query on the view column), or whether
the column in the view defines some kind of operation, rendering any
possible index on the table column useless.

From information_schema.view_column_usage I can see which columns of which
tables are referenced by the view, but it doesn't tell me whether an index
on a column in the table would be used for a query on the view.

Using 'EXPLAIN SELECT ...' does tell me whether the spatial index is used,
but the output is not machine readable. I guess the output is localized to
the current locale, so trying to parse the output doesn't seem to be a good
idea. Is there no way to get a machine readable query plan?

Any help appreciated,

Martin

Martin Schäfer <Martin.Schaefer@cadcorp.com> writes:
> Using 'EXPLAIN SELECT ...' does tell me whether the spatial index is used, 
> but the output is not machine readable. I guess the output is localized to 
> the current locale,

AFAIK it's not localized, so grepping for "Index" would probably work.

> Is there no way to get a machine readable query plan?

No, and no such API is likely to be defined in the future either,
because we reserve the right to change plan structures at any time.
        regards, tom lane

> > Is there no way to get a machine readable query plan?
>
> No, and no such API is likely to be defined in the future either,
> because we reserve the right to change plan structures at any time.

How about a list of the indices used in a query? That alone would
already be very useful.

Martin

On Mon, Jan 24, 2005 at 16:34:09 -0000, Martin Schäfer <Martin.Schaefer@cadcorp.com> wrote:
> 
> I'm using the PostGIS spatial extension. Some of my spatial queries (like 
> live zooming and panning) should only be performed when the column 
> containing the spatial data is spatially indexed, otherwise the first query 
> takes almost forever and users will just kill the application out of 
> frustration.

If the real problem is long running queries, maybe using a statement timeout
will solve your problem?

> > I'm using the PostGIS spatial extension. Some of my spatial
> queries (like
> > live zooming and panning) should only be performed when the column
> > containing the spatial data is spatially indexed, otherwise
> the first query
> > takes almost forever and users will just kill the
> application out of
> > frustration.
>
> If the real problem is long running queries, maybe using a
> statement timeout
> will solve your problem?

Using a timeout to test for the presence of an index is not exact enough: I can't guard myself against false positives
orfalse negatives. If the server is very busy at the moment all views might seem to be 'unindexed', i.e. unusable for
livezooming and panning. The next day it might look different. 

I need to know in advance whether the queries would use a spatial index on the views. If no spatial index would be
used,I have to make a local copy of (a subset of) the view (or table), create a local index and display the local copy
instead.This is better than waiting for the timeout to expire and display nothing. 

With Oracle I can fire a spatial query on a view or table, and if the spatial column is not indexed, the entire query
willfail. Unfortunately, with PostgreSQL, the spatial queries always succeed. 

Martin