Skip site navigation (1) Skip section navigation (2)

RE: [GENERAL] slow queries

From: "Jackson, DeJuan" <djackson(at)cpsgroup(dot)com>
To: Howie <caffeine(at)toodarkpark(dot)org>
Cc: pgsql-general(at)postgreSQL(dot)org
Subject: RE: [GENERAL] slow queries
Date: 1998-09-28 14:48:50
Message-ID: F10BB1FAF801D111829B0060971D839F432E37@cpsmail (view raw or flat)
Thread:
Lists: pgsql-general
> On Fri, 25 Sep 1998, Jackson, DeJuan wrote:
> > > seems that by creating a view ( with the query i mentioned before
> ),
> > > my
> > > queries were sped up by roughly 10 seconds... odd odd odd.
> > > 
> > Not really so odd when you think of everything the backend has to do
> to
> > process a query.  Parsing, planning, and optimizing (not necessarily
> in
> > that order) can be very costly.  A view basically skips most of
> those
> > three steps.
> 
> all thats taken out is the parsing bit.  the planning and optimizing
> still
> must be done ( unless its done when the view is/was created ), yesno ?
> the view should still hit the indexes created for the underlying
> tables,
> right ?
> 
Well, a view in the system is really just a stored plan.  The actual
text isn't stored afaik.  So, that tells me that there's a good chance
that the optimization step won't be revisited unless the view is
dropped.  And since the plan is the last step of the optimization step
I'd say you bypass a good deal of code.  The draw back being that if the
plan isn't redone for major table changes then the query will not be the
most efficient plan, such as adding of an index that would effect the
query or additional rows in one of the tables which would make the cost
of an index scan cheaper than a table scan. 

To answer your second question; it will hit the indexes if the plan that
was stored when the view was created hit those indexes.

pgsql-general by date

Next:From: Jackson, DeJuanDate: 1998-09-28 15:05:34
Subject: RE: [GENERAL] Long update query ?
Previous:From: David HartwigDate: 1998-09-28 13:21:08
Subject: Re: [GENERAL] Long update query ?

Privacy Policy | About PostgreSQL
Copyright © 1996-2014 The PostgreSQL Global Development Group