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
rom: [EMAIL PROTECTED]
[mailto:[EMAIL PROTECTED] On Behalf Of TJ O'Donnell Sent: Tuesday, January 25,
2005 2:19 PM
To: pgsql-general@postgresql.org
Cc: [EMAIL PROTECTED]
Subject: [GENERAL] visualizing B-tree index coverage
Does anyone know of a tools that allows one to visualize
the tree created
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
alf Of TJ O'Donnell Sent: Tuesday, January 25,
> 2005 2:19 PM
> To: pgsql-general@postgresql.org
> Cc: [EMAIL PROTECTED]
> Subject: [GENERAL] visualizing B-tree index coverage
>
> Does anyone know of a tools that allows one to visualize
> the tree created by a multi-column
lto:[EMAIL PROTECTED] On Behalf Of TJ O'Donnell
Sent: Tuesday, January 25, 2005 2:19 PM
To: pgsql-general@postgresql.org
Cc: [EMAIL PROTECTED]
Subject: [GENERAL] visualizing B-tree index coverage
Does anyone know of a tools that allows one to visualize
the tree created by a multi-column B-tree i
Does anyone know of a tools that allows one to visualize
the tree created by a multi-column B-tree index?
A picture of a tree with branches, showing how "branchy" the
tree is would be great.
I'm wondering how well I've "clustered" the data in my table
using the multi-column index. In other words,
12 matches
Mail list logo
