Re: [HACKERS] Pluggable storage

From: Haribabu Kommi <kommi(dot)haribabu(at)gmail(dot)com>
To: Alexander Korotkov <a(dot)korotkov(at)postgrespro(dot)ru>
Cc: Michael Paquier <michael(dot)paquier(at)gmail(dot)com>, Robert Haas <robertmhaas(at)gmail(dot)com>, Amit Kapila <amit(dot)kapila16(at)gmail(dot)com>, Thomas Munro <thomas(dot)munro(at)enterprisedb(dot)com>, Alvaro Herrera <alvherre(at)2ndquadrant(dot)com>, Pg Hackers <pgsql-hackers(at)postgresql(dot)org>
Subject: Re: [HACKERS] Pluggable storage
Date: 2018-01-03 07:08:51
Message-ID: CAJrrPGeoihBWs+BUP06q9=rCNm75m56J-EEStf3ygikNcpreYw@mail.gmail.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

On Wed, Dec 27, 2017 at 11:33 PM, Alexander Korotkov <
a(dot)korotkov(at)postgrespro(dot)ru> wrote:

>
> Also, I appreciate that now tuple_insert() and tuple_update() methods are
> responsible for inserting index tuples. This unleash pluggable storages to
> implement another way of interaction with indexes. However, I didn't get
> the point of passing InsertIndexTuples IndexFunc to them. Now, we're
> always passing ExecInsertIndexTuples() to this argument. As I understood
> storage is free to either call ExecInsertIndexTuples() or implement its own
> logic of interaction with indexes. But, I don't understand why do we need
> a callback when tuple_insert() and tuple_update() can call
> ExecInsertIndexTuples() directly if needed. Another thing is that
> tuple_delete() could also interact with indexes (especially when we will
> enhance index access method API), and we need to pass meta-information
> about indexes to tuple_delete() too.
>

The main reason for which I added the callback function to not to introduce
the
dependency of storage on executor functions. This way storage can call the
function that is passed to it without any knowledge. I added the function
pointer
for tuple_delete also in the new patches, currently it is passed as NULL
for heap.
These API's can be enhanced later.

Apart from rebase, Added storage shared memory API, currently this API is
used
only by the syncscan. And also all the exposed functions of syncscan usage
is
removed outside the heap.

Regards,
Hari Babu
Fujitsu Australia

Attachment Content-Type Size
0012-Storage-shared-memory-API.patch application/octet-stream 7.4 KB
0001-Change-Create-Access-method-to-include-storage-handl.patch application/octet-stream 9.3 KB
0002-Storage-AM-folder-and-init-functions.patch application/octet-stream 11.0 KB
0003-Adding-storageam-hanlder-to-relation-structure.patch application/octet-stream 7.0 KB
0004-Adding-tuple-visibility-function-to-storage-AM.patch application/octet-stream 54.0 KB
0005-slot-hooks-are-added-to-storage-AM.patch application/octet-stream 62.0 KB
0006-Tuple-Insert-API-is-added-to-Storage-AM.patch application/octet-stream 99.5 KB
0007-Scan-functions-are-added-to-storage-AM.patch application/octet-stream 104.2 KB
0008-Remove-HeapScanDesc-usage-outside-heap.patch application/octet-stream 95.7 KB
0009-BulkInsertState-is-moved-into-storage.patch application/octet-stream 10.8 KB
0010-storage-rewrite-functionality.patch application/octet-stream 11.1 KB
0011-Improve-tuple-locking-interface.patch application/octet-stream 58.5 KB

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Haribabu Kommi 2018-01-03 07:48:07 Re: Enhance pg_stat_wal_receiver view to display connected host
Previous Message Amit Khandekar 2018-01-03 06:41:19 Re: [HACKERS] UPDATE of partition key