Original Message-
From: [EMAIL PROTECTED]
[mailto:[EMAIL PROTECTED] On Behalf Of TJ O'Donnell
Sent: Thursday, January 27, 2005 7:38 AM
To: PFC
Cc: pgsql-general@postgresql.org
Subject: Re: [GENERAL] visualizing B-tree index coverage
I realize that using OR will not result in an index s
"TJ O'Donnell" <[EMAIL PROTECTED]> writes:
> However, I am concerned that I must place the most selective column first in
> my index. I cannot tell, a priori, which column will be most selective. That
> depends on the nature of search, which can vary widely each time.
If you're always using > ope
I realize that using OR will not result in an index scan.
I will never be interested in a OR condition for the kinds
of searches I use. In my Select statements, I always name
every column of the multi-column index in same order that
they were named when creating the index. I always use
the >= co
I realize that using OR will not result in an index scan.
I will never be interested in a OR condition for the kinds
of searches I use. In my Select statements, I always name
every column of the multi-column index in same order that
they were named when creating the index. I always use
the >= con
TJ O'Donnell wrote:
More specifically, I have character data representing molecular structures.
I've written (rather slow) search functions. I can create any number of
columns that "fingerprint" each structure, e.g. # Carbon atoms, # N atoms,
# single bonds, etc. I expect my fingerprints will not
I think you missed an important "feature" of multicolumn indexes, that
you better not use 'OR' in your expressions. You seem to want only to use
'>=' so this should be OK.
Suppose you have 3 columns a,z,e containing values linearly distributed
between ...
select min(a),max(a),min(z),max(z
Excuse me for bothering but what kind of search engine you
developed. Does it looks like sets comparing ?
Oleg
On Tue, 25 Jan 2005, TJ O'Donnell wrote:
Since I'm using a multi-column index, I can greatly influence
the nature of the index created, depending on which columns I use
and how man
Some other things that are important:
How much is the data in transition (updates/deletes/inserts)? If the
data is mostly static or static you can add many special case indexes
with little penalty. The biggest cost of indexes (besides disk space
consumed) is in the slowdown of inserts, updates, a
005 3:50 PM
To: pgsql-general@postgresql.org
Cc: Dann Corbit
Subject: RE: [GENERAL] visualizing B-tree index coverage
Since I'm using a multi-column index, I can greatly influence
the nature of the index created, depending on which columns I use
and how many. I'm searching for an optimal
Since I'm using a multi-column index, I can greatly influence
the nature of the index created, depending on which columns I use
and how many. I'm searching for an optimal set
of columns that creates an index that, for sure does not have
every value the same, nor only two values. Instead, I want t
Useful explanation of PostgreSQL index format:
http://www.faqs.org/docs/ppbook/c13329.htm
I think you are aiming for the wrong thing.
The worst possible index is one with every value the same.
The second worst (still basically useless) is one with only two values.
The greater the differentiation o
11 matches
Mail list logo
