I tried posting this on LSSTC Slack but almost certainly the wrong channel as I used the qserv-users one.
i) post DP0.3, will solar system data releases be published in qserv or continue to be published in Postgres?
ii) Although I think we’ve solved the issues we encountered, what’s the best place/channel to ask DP0.3 Postgres related questions in future?
We hadn’t realised that Postgres doesn’t really support queries between databases (without mods/extensions) so initially set-up our DP0.3 incorrectly with 10yr and 1yr databases rather than 10yr and 1yr schemas in the same database.
Thanks!
Mike
Regarding question (i): DP0.3 uses the same backend, postgres, as the future solar system tables will, as part of the prompt products database, referencing Rubin technote RTN-050. In particular Section 4 says "In the operations-era system, the SSO tables will live in the “Prompt Products Database” (PPDB), which is baselined as PostgreSQL ".
About question (ii): The forum is always the best place to ask questions about the LSST data products and services. So you’ve come to the right place! But, in case I misunderstood your question, is it possible to provide more information on what issues you encountered that you were able to resolve, and who is the we that might help us understand the scope of the answer you need?
I think this answers your questions (i) and (ii) so I’ve marked this as the solution but please do reply to this, or start a new topic any time, with further questions or issues. Thanks!
Many thanks Christina and fine to be marked as solved!
We’d ingested DP0.3 here in the UK DAC but when exposed via SSOTAP noticed the 1yr tables were not queryable. We hadn’t appreciated both sets of tables had to be in the same database but under different schemas as we are new to postgresSQL.
Alongside this, we’re looking at moving a lot of our legacy datasets to postgresSQL but we make use of cross database queries so were a bit surprised to encounter this limitation. Which prompted us to ask would future solar system releases continue in postgresSQL.