Re: [WIP]Vertical Clustered Index (columnar store extension) - take2

On Wed, Jul 30, 2025 at 4:39 PM Japin Li <japinli@hotmail.com> wrote:
>
> On Wed, 30 Jul 2025 at 14:49, Peter Smith <smithpb2250@gmail.com> wrote:
> > On Fri, Jul 25, 2025 at 1:58 PM Japin Li <japinli@hotmail.com> wrote:
> >>
> >> On Wed, 23 Jul 2025 at 14:07, Peter Smith <smithpb2250@gmail.com> wrote:
> >> > On Tue, Jul 22, 2025 at 8:12 PM Japin Li <japinli@hotmail.com> wrote:
> >> > ...
> > ...
> >> >>
> >> >> Or is it by design that users are unable to read the internal relations?
> >> >>
> >> >
> >> > IIUC, those VCI internal relations (implemented as materialized views)
> >> > are entirely managed by VCI logic. Users are not required to be aware
> >> > of them, and they definitely are not meant to tamper with them.
> >> >
> >>
> >> Thanks for your explanation!
> >>
> >> > The REFRESH that you attempted should have caused a more graceful error, like:
> >> > ERROR:  extension "vci" prohibits this operation on view
> >> > "vci_0000016482_00000_d"
> >> > So, thanks for reporting that the ERROR failed. Investigating...
> >>
> >> I'm considering storing this metadata in heap tables, as Citus Columnar [1]
> >> and TimescaleDB [2] also utilize them for some metadata. Is this a sound
> >> approach? I'm wondering if this is a suitable strategy for VCI?
> >>
> >> [1] https://github.com/citusdata/citus/blob/main/src/backend/columnar/columnar_metadata.c#L174
> >> [2] https://github.com/timescale/timescaledb/blob/main/src/chunk.c#L151
> >>
> >
> > Hi Japin,
> >
> > TL;DR;
> > ------
> > What metadata relations did you have in mind to change, how do you
> > want to change them, and what is the main motivation?
> >
>
> I've noticed a strange user experience with vci_xxx_{d,m}. Although they are
> defined as materialized views, they cannot be queried, leading to an error
> that suggests using REFRESH MATERIALIZED VIEW. However, that command is also
> rejected.  This is my motivation.

FYI, the query is made possible now in v16. The result will be
meaningless, but the error and misleading HINT will no longer happen.

======
Kind Regards,
Peter Smith.
Fujitsu Australia