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.
