Re: Tuning to speed select

I'm not so sure about that, when you create a view on a table - at least
with Oracle - which is a subset(the trivial or 'proper' subset is the
entire table view) of the information on a table, when a select is
issued against a table, Oracle at least, determines if there is a view
already on a the table which potentially has a smaller amount of
information to process - as long as the view contains the proper
constraints that meet your 'select' criteria, the RDBMS engine will have
fewer records to process - which I'd say, certainly constitutes a time
benefit, in terms of 'performance gain.'

Hence my reasoning behind determining IF there is a subset of the 'big
table' that is frequented, I'd create a view on this, assuming
postgresql does this too?  Maybe somebody else can answer that for the
pgsql-general's general information?

query-speed itself is going to be as fast/slow as your system is
configured for, however my point was to shave some time off of a 1M+
record table, but implementing views of 'frequently' visisted/hit
records meeting the same specifications.

Harald Armin Massa wrote:

> Louis,
>
> Views certainly help in managing complexity. They do nothing to
> improve query-speed.
>
> Querying a view gets rewritten to queries to the underlying tables on
> the fly.
> (as long as there are no materialized views, which are still on a the
> TODO list)
>
> --
> GHUM Harald Massa
> persuadere et programmare
> Harald Armin Massa
> Reinsburgstraße 202b
> 70197 Stuttgart
> 0173/9409607
> -
> Let's set so double the killer delete select all.