RE: [WIP]Vertical Clustered Index (columnar store extension) - take2 - Mailing list pgsql-hackers

From Aya Iwata (Fujitsu)
Subject RE: [WIP]Vertical Clustered Index (columnar store extension) - take2
Date
Msg-id TYWPR01MB890148F5209E8E6AFD6A8D08EA60A@TYWPR01MB8901.jpnprd01.prod.outlook.com
Whole thread Raw
In response to Re: [WIP]Vertical Clustered Index (columnar store extension) - take2  (Alexandre Felipe <o.alexandre.felipe@gmail.com>)
Responses RE: [WIP]Vertical Clustered Index (columnar store extension) - take2
List pgsql-hackers
Hi Alexandre-san

Thank you for summarizing the strategy. I agreed your design principle.
Per your phase, I feel we are on the phase 0 or 1, we can first commit the basic architecture.

> Note:
> I had different expectations, the first query uses two columns and filters over a 1-year period, the second query
usesonly one column and filters over.
 
> My first expectation was that if only one column is used there is less data being accessed.
> In my experience most queries will care about a timestamp column, it would be nice to be able to cluster the data by
certaincolumns (in my case the created) column
 
> Maybe even clustering by multiple columns independently mediated by CRID permutations. If you think that this is easy
enoughwe could insert this before phase 3.
 

The number of rows accessed by the first query and the number of
rows in the second query differ significantly.
This isn't only because one query uses a single column. Therefore,
I understood the advice to be that even when using VCI, it would be
beneficial to enable clustering on another column,
such as the created column, right?

Best regards,
Aya Iwata

pgsql-hackers by date:

Previous
From: Anthonin Bonnefoy
Date:
Subject: Re: LLVM 22
Next
From: Dean Rasheed
Date:
Subject: Re: Allow ON CONFLICT DO UPDATE to return EXCLUDED values