| From: | Jim Nasby <Jim(dot)Nasby(at)BlueTreble(dot)com> |
|---|---|
| To: | Andres Freund <andres(at)anarazel(dot)de> |
| Cc: | Greg Stark <stark(at)mit(dot)edu>, PostgreSQL-development <pgsql-hackers(at)postgresql(dot)org> |
| Subject: | Re: Rethinking TupleTableSlot deforming |
| Date: | 2016-07-22 19:06:50 |
| Message-ID: | 9df6edb7-bac2-3fea-3d67-cce9ae4fec7e@BlueTreble.com |
| Views: | Raw Message | Whole Thread | Download mbox | Resend email |
| Thread: | |
| Lists: | pgsql-hackers |
On 7/22/16 1:58 PM, Andres Freund wrote:
> On 2016-07-22 13:51:31 -0500, Jim Nasby wrote:
>> Another option would be to remember the
>> tuple offsets (NOT attcacheoff) that have
>> been computed as well as whether a
>> varlena attribute has actually been
>> deformed. That eliminates the need to
>> pre-declare what attributes you're
>> allowed to reference.
>
> That'd make access more expensive, so that doesn't seem a very enticing
> solution.
Yeah, it's certainly a tradeoff. The advantage is this might be less
invasive; it might also work in more cases like heap_deform_tuple (which
I think is used a lot more than table slots).
It's certainly possible it's not worth it, but I wanted to put the idea
out there.
--
Jim Nasby, Data Architect, Blue Treble Consulting, Austin TX
Experts in Analytics, Data Architecture and PostgreSQL
Data in Trouble? Get it in Treble! http://BlueTreble.com
855-TREBLE2 (855-873-2532) mobile: 512-569-9461
| From | Date | Subject | |
|---|---|---|---|
| Next Message | Andres Freund | 2016-07-22 19:15:40 | Re: Rethinking TupleTableSlot deforming |
| Previous Message | Merlin Moncure | 2016-07-22 19:04:04 | Re: Bug with plpgsql handling of NULL argument of compound type |