From: | Alvaro Herrera <alvherre(at)2ndquadrant(dot)com> |
---|---|
To: | Andres Freund <andres(at)anarazel(dot)de> |
Cc: | pgsql-hackers(at)postgresql(dot)org |
Subject: | Re: Rethinking TupleTableSlot deforming |
Date: | 2016-07-27 20:05:31 |
Message-ID: | 20160727200531.GA62658@alvherre.pgsql |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
Andres Freund wrote:
> Hi,
>
> I've previously mentioned (e.g. [1]) that tuple deforming is a serious
> bottlneck. I've also experimented successfully [2] making
> slot_deform_tuple() faster.
I'm currently messing with making heapam.c be just one possible
implementation of tuple storage, to allow other modules to implement
tuple storage in different ways. Each such module would have a pg_am
row, and among the set of routines that such a module would have to
provide is the equivalent of slot_deform_tuple, which takes a tuple in
whatever format the storage module uses and puts it into
executor-formatted tts_values/tts_isnull arrays. For tuples coming from
heapam.c-formatted tables that would be pretty much slot_deform_tuple,
but of course other modules could have tuples in completely different
formats.
(This is one part in the larger project of columnar storage, where a
storage module would store tuples in some columnar format rather than
row-oriented. Obviously, tuple deforming means a completely different
thing in that world than in heapam.c).
No patch to show at present; I mentioned this project in Brussels.
I intend to present for 10.0.
--
Álvaro Herrera http://www.2ndQuadrant.com/
PostgreSQL Development, 24x7 Support, Remote DBA, Training & Services
From | Date | Subject | |
---|---|---|---|
Next Message | Bruce Momjian | 2016-07-27 20:35:06 | Re: A Modest Upgrade Proposal |
Previous Message | Tom Lane | 2016-07-27 18:47:25 | Fixing target-column indirection in INSERT with multiple VALUES |