The index is a B-Tree, not hashed. The order of the segments of the key
makes a big difference to queries, as pointed out earlier. It doesn't
make any significant difference to the time it takes to create of
maintain the index.
JS
Taka wrote:
Ah, maybe I wasn't quite clear enough.
What I
Taka wrote:
Ah, maybe I wasn't quite clear enough.
What I meant was, is there any performance difference between:
CREATE INDEX ON my_table ( a , b , c )
and
CREATE INDEX ON my_table ( c , b , a )
I'm guessing not, presumably because the index is using some kind of
hashing but I thought I'd
Ah, maybe I wasn't quite clear enough.
What I meant was, is there any performance difference between:
CREATE INDEX ON my_table ( a , b , c )
and
CREATE INDEX ON my_table ( c , b , a )
I'm guessing not, presumably because the index is using some kind of hashing
but I thought
Taka wrote:
Does it make a difference what order the columns are specified when
creating an index?
Yes. An index on colums (a, b, c, d) can also speed up search on column
a, on a pair of columns (a, b) and on a triple (a, b, c). If you have a
query with a where clause looking like "where
@list
Following the documentation, the two functions have been declared
'experimental'. Does someone know, how reliable these calls are actually
? There are specific serious open issues, rough estimates when to fix
them, etc. ?
Micha
5 matches
Mail list logo