Obscore 1.1 Erratum 3

[Renaud Savalle]

Hi Markus,

On 2022-12-09 10:41, Markus Demleitner wrote:
>
>>> But the background of the erratum is not that having obs_id non-NULL
>>> is hard to do, it is that it is hard to validate.  Which of course
>>> would be perfectly ok if the requirement served a purpose, but since
>>> we still have not identified such a purpose, it would make
>>> implementors' lives substantially easier at no cost (well: that's
>>> admittedly my claim) if we dropped it.
>> Technically as far as I understood the problem occurs only with ObscOre
>> tables implemented as "views", because otherwise you can always create an
>> index on this obs_id column.
>>
>> Apparently "material views" can have indexes. So why not use them when
>> available in your dbms ?
> Because creating such a materialised view takes several minutes when
> you have ~1e8 rows -- and it's something that you do whenever you
> import new images or spectra on any contributing data collections.
> This is just not a sensible option.

Could "REFRESH MATERIALIZED VIEW *CONCURRENTLY*" help ? This allows to refresh a view with new data without blocking read access. A PK is needed in the materialized view to do that.

I heard about that feature last year in https://archive.fosdem.org/2022/schedule/event/postgresql_automatically_refresh_materialized_views_in_postgresql/

My 2 cents (and sorry if I am off-topic) !

Renaud.

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.ivoa.net/pipermail/dm/attachments/20221209/6a8921bc/attachment.htm>