Thread: 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