This is the mail archive of the guile@cygnus.com mailing list for the guile project.
| Index Nav: | [Date Index] [Subject Index] [Author Index] [Thread Index] | |
|---|---|---|
| Message Nav: | [Date Prev] [Date Next] | [Thread Prev] [Thread Next] |
Tel <telford@eng.uts.edu.au> writes: > As far as I know, SQL doesn't support hash tables because there is > no way to tell it that you don't care about the sort order for your > table. Does anyone know the deal with this? As far as I know, there's nothing stopping an SQL implementation using a hash table; there's certainly nothing stopping an SQL implementation from not having an index on some fields at all (indeed, that's normal). Queries can ask for tuples to be returned ORDERed BY something, or not mention any ordering. One would expect a hash index to provide worse performance (than an index with ordering) when returning things ordered (depending on the size of the table). Indeed, I seem to remember that PostgreSQL *does* support hash indexes (as well as the default b-tree indexes), but I may be wrong. In any case, all this is just an implementation detail. Database clients should never need to know what indexes are present; indeed, new indexes can be created, and old ones deleted---all dynamically---without changing client code. That's one of the important features of relational databases.