Обсуждение: which will be faster? w/ or w/o indices

I understand that if you are importing data into the database
that this will go faster if there are no indices against the
target table.

If I want to run this statement:
INSERT INTO table_a SELECT * from table_b WHERE value_1 BETWEEN
X AND Y;
is it best to do that with or without indices?

AND, if I want to run this statement:
DELETE FROM table_B WHERE value_1 BETWEEN X AND Y;
is it best to do that with or without indices?


We are using v 7.2.1 on a Sun E4500.

TIA,
val

> I understand that if you are importing data into the database
> that this will go faster if there are no indices against the
> target table.
>
> If I want to run this statement:
> INSERT INTO table_a SELECT * from table_b WHERE value_1 BETWEEN
> X AND Y;
> is it best to do that with or without indices?

Can't really say without testing - it'll depend on the size of the various
tables, X and Y disk speeds etc. The only suggestion I can make is to try
an EXPLAIN (Reference manual, SQL commands) with and without
ENABLE_SEQSCAN off (Admin guide ch 3.2).


- Richard Huxton

Val,

> Can't really say without testing - it'll depend on the size of the various
> tables, X and Y disk speeds etc. The only suggestion I can make is to try
> an EXPLAIN (Reference manual, SQL commands) with and without
> ENABLE_SEQSCAN off (Admin guide ch 3.2).

Please use EXPLAIN ANALYZE instead of just EXPLAIN.    That will show you
whether you have performance problems due to things outside of the planner's
control.

Keep in mind, though, that if your system has no special problems and your
planner statistics are up to date, the planner will do a good job of deciding
whether or not indexes are faster.   You don't need to start out
second-guessing the planner ... you're likely to be wrong more often that it
is.   Save that for real problem queries.

Also, upgrade to 7.2.4!!!    7.2.1 has several significant bugs, including two
security exploits and one backup-and-restore bug that could make it difficult
to recover your database from a backup file.

--
Josh Berkus
Aglio Database Solutions
San Francisco