Re: Zedstore - compressed in-core columnar storage

From: Peter Geoghegan <pg(at)bowt(dot)ie>
To: Ashwin Agrawal <aagrawal(at)pivotal(dot)io>
Cc: Rafia Sabih <rafia(dot)pghackers(at)gmail(dot)com>, PostgreSQL mailing lists <pgsql-hackers(at)postgresql(dot)org>
Subject: Re: Zedstore - compressed in-core columnar storage
Date: 2019-04-15 19:50:14
Message-ID: CAH2-Wz=FWjJPB-gAWQD42amdnAh7n0L7ZvuV6QAbbh0YKXGU3w@mail.gmail.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

On Mon, Apr 15, 2019 at 9:16 AM Ashwin Agrawal <aagrawal(at)pivotal(dot)io> wrote:
> Would like to know more specifics on this Peter. We may be having different context on hybrid row/column design.

I'm confused about how close your idea of a TID is to the traditional
definition from heapam (and even zheap). If it's a purely logical
identifier, then why would it have two components like a TID? Is that
just a short-term convenience or something?

> Yes, the plan to optimize out TID space per datum, either by prefix compression or delta compression or some other trick.

It would be easier to do this if you knew for sure that the TID
behaves almost the same as a bigserial column -- a purely logical
monotonically increasing identifier. That's why I'm interested in what
exactly you mean by TID, the stability of a TID value, etc. If a leaf
page almost always stores a range covering no more than few hundred
contiguous logical values, you can justify aggressively compressing
the representation in the B-Tree entries. Compression would still be
based on prefix compression, but the representation itself can be
specialized.

--
Peter Geoghegan

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Andres Freund 2019-04-15 20:02:47 Re: Zedstore - compressed in-core columnar storage
Previous Message Tom Lane 2019-04-15 19:46:58 Re: New vacuum option to do only freezing