From: | TJ O'Donnell <tjo(at)acm(dot)org> |
---|---|
To: | pgsql-general(at)postgresql(dot)org |
Subject: | how to optimize my c-extension functions |
Date: | 2005-01-08 23:50:06 |
Message-ID: | 41E071AE.6070406@acm.org |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-general |
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. In order to optimize this search, I'd like to parse the whole
table containing smiles just once, store it and use the parsed data
instead of the varchar smiles.
So, I could create another column, say smiles_ob and have the
oe_matches function take that column. I'd have to be sure the smiles_ob
column was related (by a trigger?) to the smiles column.
But I was thinking I might be able to hide these parsed objects from the
user by somehow incoporating the parsed objects into a type of index.
I'd like also to use additional columns (like molecular formula) in
the match function to "triage" the table to quickly rule out impossible
matches, before doing a full search/match.
Am I way off the track here? Is it a bad idea to clutter the index
with things like this? Is it possible? Is there another
approach that could hide some of these details from the user - meaning
they would not have to create/update these additional columns?
Thanks,
TJ O'Donnell
From | Date | Subject | |
---|---|---|---|
Next Message | mstory | 2005-01-09 00:01:01 | PYTHON, ODBC |
Previous Message | Jeff Davis | 2005-01-08 23:24:36 | PITR questions |