Re: Pluggable storage

From: Haribabu Kommi <kommi(dot)haribabu(at)gmail(dot)com>
To: Alvaro Herrera <alvherre(at)2ndquadrant(dot)com>
Cc: Pg Hackers <pgsql-hackers(at)postgresql(dot)org>
Subject: Re: Pluggable storage
Date: 2017-06-13 01:50:27
Message-ID: CAJrrPGfG7BarSFb6KQkOOYVaC6vjQRgG45+J2+TwLHHaFKuwGA@mail.gmail.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

On Fri, Oct 14, 2016 at 7:26 AM, Alvaro Herrera <alvherre(at)2ndquadrant(dot)com>
wrote:

> I have sent the partial patch I have to Hari Babu Kommi. We expect that
> he will be able to further this goal some more.

Thanks Alvaro for sharing your development patch.

Most of the patch design is same as described by Alvaro in the first mail
[1].
I will detail the modifications, pending items and open items (needs
discussion)
to implement proper pluggable storage.

Here I attached WIP patches to support pluggable storage. The patch series
are may not work individually. Still so many things are under development.
These patches are just to share the approach of the current development.

Some notable changes that I did to make the patch work:

1. Added storageam handler to the slot, this is because not all places
the relation is not available in handy.
2. Retained the minimal Tuple in the slot, as this is used in HASH join.
As per the first version, I feel it is fine to allow creating HeapTuple
format data.

Thanks everyone for sharing their ideas in the developer's unconference at
PGCon Ottawa.

Pending items:

1. Replacement of Tuple with slot in Trigger functionality
2. Replacement of Tuple with Slot from storage handler functions.
3. Remove/minimize the use of HeapTuple as a Datum.
4. Replace all references of HeapScanDesc with StorageScanDesc
5. Planner changes to consider the relation storage during the planning.
6. Any planner changes based on the discussion of open items?
7. some Executor changes to consider the storage advantages?

Open Items:

1. The BitmapHeapScan and TableSampleScan are tightly coupled with
HeapTuple and HeapScanDesc, So these scans are directly operating
on those structures and providing the result.

These scan types may not be applicable to different storage formats.
So how to handle them?

Currently my goal to provide a basic infrastructure of pluggable storage as
a first step and later improve it further to improve the performance by
taking the advantage of storage.

[1] - https://www.postgresql.org/message-id/20160812231527.
GA690404%40alvherre.pgsql

Regards,
Hari Babu
Fujitsu Australia

Attachment Content-Type Size
0010-compilation-fixes.patch application/octet-stream 1.2 KB
0001-Create-Access-method-change-to-include-storage-handl.patch application/octet-stream 7.0 KB
0002-Regression-suite-update-according-to-the-new-access-.patch application/octet-stream 2.9 KB
0003-Storage-access-method-API-functions.patch application/octet-stream 13.3 KB
0004-Heap-storage-handler.patch application/octet-stream 36.9 KB
0005-Adding-storageam-handler-to-slot.patch application/octet-stream 22.8 KB
0006-HeapTuple-replace-with-StorageTuple.patch application/octet-stream 83.1 KB
0007-Replace-slot-functions-with-storage-access-methods.patch application/octet-stream 22.9 KB
0008-Replace-heap_-functions-with-storage-access-methods.patch application/octet-stream 63.4 KB
0009-Remaining-heap_insert-calls-repalce.patch application/octet-stream 2.9 KB

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Michael Paquier 2017-06-13 02:16:54 Re: Race conditions with WAL sender PID lookups
Previous Message Masahiko Sawada 2017-06-13 01:32:37 Fix a typo in shm_mq.c