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

Yura Sokolov <y.sokolov@postgrespro.ru>

From: Yura Sokolov <y.sokolov@postgrespro.ru>

To: pgsql-hackers@lists.postgresql.org

Date: 2025-01-15T14:43:46Z

Lists: pgsql-hackers

Commits

Same data as JSON: GET /api/v1/messages/:b64id/commits the thread's linked commits as JSON, with link sources. API reference →

Mark ItemPointer arguments as const throughout
- e1ac846f3d28 19 (unreleased) cited
Reorganize GUC structs
- a13833c35f9e 19 (unreleased) cited
Eliminate XLOG_HEAP2_VISIBLE from vacuum phase III
- add323da40a6 19 (unreleased) cited
Update various forward declarations to use typedef
- d4d1fc527bdb 19 (unreleased) cited
Pathify RHS unique-ification for semijoin planning
- 24225ad9aafc 19 (unreleased) cited
Revert "Don't lock partitions pruned by initial pruning"
- 1722d5eb05d8 18.0 cited
For inplace update, send nontransactional invalidations.
- 243e9b40f1b2 18.0 cited
Remove nearly-unused SizeOfIptrData macro.
- 8023b5827fba 10.0 cited

07.10.2024 17:53, Aya Iwata (Fujitsu) wrote:
> Hi All,
> 
> Suggestions
> 
> ==========
> 
> When analyzing real-time data collected by PostgreSQL,
> 
> it can be difficult to tune the current PostgreSQL server for 
> satisfactory performance.
> 
> Therefore, we propose Vertical Clustered Indexing (VCI), an in-memory 
> column store function that holds data in a state suitable for business 
> analysis and is also expected to improve analysis performance.

I just don't get, why it should be "in-memory"? All the same things you 
describe further, but storing in paged index on-disk with caching 
through shared_buffers - why this way it wouldn't work?