On 2019-05-20 04:23, David Rowley wrote:
> On Thu, 16 May 2019 at 05:44, Peter Eisentraut
> wrote:
>> Updated patch attached.
>
> This patch looks okay to me.
committed
--
Peter Eisentraut http://www.2ndQuadrant.com/
PostgreSQL Development, 24x7 Support, Remote DBA, Training & Ser
Hi,
On 2019-05-20 14:23:34 +1200, David Rowley wrote:
> It's not for this patch, or probably for PG12, but it would be good if
> we could avoid the formation of the Tuple until right before the new
> tuple is inserted.
>
> I see heap_form_tuple() is called 3 times for a single INSERT with:
>
> cre
On Thu, 16 May 2019 at 05:44, Peter Eisentraut
wrote:
> Updated patch attached.
This patch looks okay to me.
It's not for this patch, or probably for PG12, but it would be good if
we could avoid the formation of the Tuple until right before the new
tuple is inserted.
I see heap_form_tuple() is
On 2019-04-24 00:26, David Rowley wrote:
> I didn't do the exact same test, but if I use COPY instead of \copy,
> then for me patched is faster.
OK, confirmed that way, too.
> For the patch, I wonder if you need this line:
>
> + memcpy(values, slot->tts_values, sizeof(*values) * natts);
>
> If
On Tue, 23 Apr 2019 at 20:23, Peter Eisentraut
wrote:
> The attached patch is based on your sketch. It's clearly better in the
> long term not to rely on heap tuples here. But in testing this change
> seems to make it slightly slower, certainly not a speedup as you were
> apparently hoping for.
On 2019-04-01 11:23, Peter Eisentraut wrote:
> On 2019-03-31 04:57, Andres Freund wrote:
>> while rebasing the remaining tableam patches (luckily a pretty small set
>> now!), I had a few conflicts with ExecComputeStoredGenerated(). While
>> resolving I noticed:
>
> The core of that code was writte
Hi,
On 2019-04-01 11:25:46 +0200, Peter Eisentraut wrote:
> On 2019-03-31 05:00, Andres Freund wrote:
> > Also, have you actually benchmarked this code? ISTM that adding a
> > stored generated column would cause quite noticable slowdowns in the
> > COPY path based on this code.
>
> Yes, it'll be
On 2019-03-31 05:00, Andres Freund wrote:
> Also, have you actually benchmarked this code? ISTM that adding a
> stored generated column would cause quite noticable slowdowns in the
> COPY path based on this code.
Yes, it'll be slower than not having it, but it's much faster than the
equivalent tri
On 2019-03-31 04:57, Andres Freund wrote:
> while rebasing the remaining tableam patches (luckily a pretty small set
> now!), I had a few conflicts with ExecComputeStoredGenerated(). While
> resolving I noticed:
The core of that code was written a long time ago and perhaps hasn't
caught up with al
Hi,
On 2019-03-30 19:57:44 -0700, Andres Freund wrote:
> while rebasing the remaining tableam patches (luckily a pretty small set
> now!), I had a few conflicts with ExecComputeStoredGenerated(). While
> resolving I noticed:
>
> oldtuple = ExecFetchSlotHeapTuple(slot, true, &should_free);
>
Hi,
while rebasing the remaining tableam patches (luckily a pretty small set
now!), I had a few conflicts with ExecComputeStoredGenerated(). While
resolving I noticed:
oldtuple = ExecFetchSlotHeapTuple(slot, true, &should_free);
newtuple = heap_modify_tuple(oldtuple, tupdesc, valu
11 matches
Mail list logo
