Hi Brian,
I just did a bit of looking here and either something has changed since my
first experiments with 9.6 or I was remembering incorrectly. The functions
exposed in the cartridge need to be marked as being "parallel safe" in
order to be usable in a parallel query. At the moment none of them
Doesn't appear like ::mol parallelized either. Only seeing the following
use 1 CPU in top.
ligandlibrary=# explain analyze select count(*) from ligands where
rdkit_mol@>'Br'::mol;
QUERY PLAN
I think they should. Does a ::mol query on the same table parallelize? If
it does but a ::qmol query does not maybe I forgot something in the SQL
function definitions
On Fri, 1 Jun 2018 at 15:43, Brian Cole wrote:
> Hi Greg,
>
> Are SMARTS searches with the ::qmol type supposed to parallelize?
Hi Greg,
Are SMARTS searches with the ::qmol type supposed to parallelize? They
don't appear to be either.
-Brian
On Fri, Jun 1, 2018 at 1:46 AM, Greg Landrum wrote:
> Hi Brian,
>
> When the new parallel queries came out I checked that they actually could
> be used and things seemed fine.
>
Hi Brian,
When the new parallel queries came out I checked that they actually could
be used and things seemed fine.
The problem (and it's a sizable one) is that parallel queries don't use the
index. Until parallel scans using GIST indices work, I don't think this is
really going to help much.
It appears like Postgres 9.6+ supports parallel queries now to accelerate
slow queries:
https://www.postgresql.org/docs/10/static/parallel-query.html
Has anyone successfully got this to accelerate substructure queries with
the RDKit Postgres cartridge?
Thanks,
Brian
6 matches
Mail list logo
