That's not what I meant...
I meant, what does 'c1c1C(=O)N' means ?
If the search operation is too slow, you can narrow it using standard
postgres tools and then hand it down to your C functions. Let me explain,
I have no clue about this 'c1c1C(=O)N' syntax, but I'll suppose you
I was not hoping that indexing, per se, would help me.
In fact, indexing smiles would be of virtually no use
to me, except for exact matches, e.g. where smiles = 'CCCOC';
I was only trying to subvert the use of indexing for
my own purposes, to store the parsed smiles somewhere
automatic for the sql
"TJ O'Donnell" <[EMAIL PROTECTED]> writes:
> The only type of search will be of the type:
> Select smiles,id from structure where oe_matches(smiles,'c1c1C(=O)N');
You haven't really said much about how you expect an index to be able to
help you with this, but I think if any index type can he
Let me first say that I will routinely be dealing with
one million+ rows, so I want to take care to optimize
my work as much as possible, and to consider carefully
my design decisions.
The only type of search will be of the type:
Select smiles,id from structure where oe_matches(smiles,'c1c1C(=
Well, first and easy thing you can do is create a column to store the
parsed representation and update it via a trigger when the original,
unparsed column is updated or inserted.
Is this sufficiently "hidden from the user" for you ? I know it's not
really hidden, but the fact that updating
To add to my last followup posting, the only way I use
oe_mathces(smiles) is in something like the following:
Select smiles,id from structure where oe_matches(smiles,'CCOC');
The match string 'CCOC' in this case, varies widely according to
the needs of the user during that session.
It is analogous
Yes, my c function and it's sql counterpart, oe_matches(smiles)
uses two steps (1) parse smiles (2) search parsed smiles.
Parsing is expensive. The smiles has an external string representation,
which is stored in a smiles column, but only the parsed form is actually
searchable.
The smiles represe
I gather your program uses two steps, let's call them :
- parse( smiles ) -> data
- search( data ) -> result
You can create a functional index on your smiles column, but I don't know
if this will help you ; you can do things like CREATE INDEX ... ON
mytable( lower( myfi
I've written a c-language extension to postgresql to implement a
chemical search of a varchar column (named smiles, typically).
It might be called as:
oe_matches(smiles,'COCC') where 'COCC' is a typical search string.
This uses 3rd party functions to parse the varchar inputs into c++
objects. I
