Fritz Mueller added a comment - 09/Nov/16 6:38 PM A similar query for a known-loaded objectId in the qserv cluster executes correctly: select * from RunDeepForcedSource where objectId=3448068867358968;

Igor Gaponenko added a comment - 09/Nov/16 6:54 PM The problem has been investigated. And here is the conclusion: The object in question belongs to the overlap area processed during S13 DC by IN2P3 in patch=366,0 . The IN2P3's version of the patch was not included into the merged Stripe82 catalog. The NCSA's version was used instead. User hit a very narrow hole in the merged dataset right on the edge. Note that this is a well known problem with the current version of the Stripe82 catalog loaded into PDAC/Qserv database sdss_stripe82_00 . The problem is well understood, and it will be solved in a refined version of the catalog. I picked that patch by a pure accident when preparing that tiny monolithic catalog for SUIT in an anticipation of the PDAC deployment. I wouldn't draw any conclusions from this as this monolithic catalog is not meant to be used to Q&A PDAC! For that (later) purpose we're planning to have the full merged catalog on some dedicated hardware....when/if it will be available.

Igor Gaponenko added a comment - 09/Nov/16 6:59 PM - edited This is how the patch info could be found from the original (before the merge) version of the catalog brought from IN2P3: USE lsst_prod_DC_2013_2; SELECT id,coadd_id FROM RunDeepSource WHERE id=3219370448785419; +------------------+----------+ | id | coadd_id | +------------------+----------+ | 3219370448785419 | 23986179 | +------------------+----------+ SELECT deepCoaddId,tract,patch FROM DeepCoadd WHERE deepCoaddId=23986179; +-------------+-------+-------+ | deepCoaddId | tract | patch | +-------------+-------+-------+ | 23986179 | 0 | 366,0 | +-------------+-------+-------+