Re: genomic locus

From: Teodor Sigaev <teodor(at)sigaev(dot)ru>
To: Gene Selkov <selkovjr(at)gmail(dot)com>, Craig Ringer <craig(at)2ndquadrant(dot)com>
Cc: PostgreSQL Hackers <pgsql-hackers(at)postgresql(dot)org>
Subject: Re: genomic locus
Date: 2017-12-22 07:49:12
Message-ID: abf4c37d-a307-9a70-1cf4-f00ff32dd15d@sigaev.ru
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

Hi!

> Problem 1. What is a union of ‘1:6000-7000’ and ‘X:10000-20000’? Intuitively, it
> should be NULL, however, I am not sure the method allows for that; it was
> developed for objects living in the same metric space. I have mechanistically
> reproduce the indexing methods of seg, but the resulting index is broken. All
> queries against an indexed table return a null result.
You can use fixed-size signature for string part (contig?) of locus, it will
help to find that string part by equlity or intersection of need it. Signature
of inner key should be bitwise-ORed of all child keys. Looking on query example,
seems, you need to build signature tree and, if signature is the same of two
key, take into account start-end range.

> Problem 2. While the intersection (overlap, &c.) of any two loci produces
> obvious results, non-intersection does not. When I query for all loci not
> overlapping ‘1:6000-7000’, I expect to find all non-overlapping loci on contig
> 1. I don’t want the query to return anything from other contigs, because it is
> obvious that features on different contigs do not overlap. I may be able to fix
> that by making separate functions for non-overlaps and adding a constraint to
> them, but that seems like a kludge.
Seems like you have two different non-overlap operation...

> Problem 3 (alternative to 1). I realize that any clustering can help build an
> efficient index, no matter how bizarre. So I could, for example, ignore the
> contigs altogether and build a single index tree, using only position
> co-ordinates and pretending that all positions are on the same contig; the
> question then is whether and how such lossy index will affect the ordering of
> query results. Can I use a separate function for ordering? I have yet to make an
> experiment. Not that this would be equivalent to indexing the attributes of a
> composite type separately (if I understood it correctly).
>
Ordering and GiST aren't very close things :) You can try to have a look to
KNN-search feature of GiST. https://www.pgcon.org/2010/schedule/events/227.en.html

--
Teodor Sigaev E-mail: teodor(at)sigaev(dot)ru
WWW: http://www.sigaev.ru/

In response to

Browse pgsql-hackers by date

  From Date Subject
Next Message Teodor Sigaev 2017-12-22 07:53:46 Re: genomic locus
Previous Message Yugo Nagata 2017-12-22 07:19:46 Re: [HACKERS] [PATCH] Lockable views