On Wed, May 26, 2021 at 12:49 PM tsunakawa.ta...@fujitsu.com
wrote:
>
> From: Bharath Rupireddy
> > I think the "New Table Access Methods for Multi and Single Inserts"
> > patches at [1] make multi insert usage easy for COPY, CTAS/Create Mat
> > View, Refresh Mat View and so on. It also has a pat
From: Bharath Rupireddy
> I think the "New Table Access Methods for Multi and Single Inserts"
> patches at [1] make multi insert usage easy for COPY, CTAS/Create Mat
> View, Refresh Mat View and so on. It also has a patch for multi
> inserts in CTAS and Refresh Mat View
> (v6-0002-CTAS-and-REFRESH
On Wed, May 26, 2021 at 12:18 PM tsunakawa.ta...@fujitsu.com
wrote:
>
> Hello Paul-san,
>
> From: Daniel Gustafsson
> > In an off-list discussion with Paul, we decided to withdraw this patch for
> > now
> > and instead create a new entry when there is a re-worked patch. This has
> > now
> > bee
Hello Paul-san,
From: Daniel Gustafsson
> In an off-list discussion with Paul, we decided to withdraw this patch for now
> and instead create a new entry when there is a re-worked patch. This has
> now
> been done in the CF app.
Would you mind if I take over this patch for PG 15? I find this p
In an off-list discussion with Paul, we decided to withdraw this patch for now
and instead create a new entry when there is a re-worked patch. This has now
been done in the CF app.
cheers ./daniel
I took some time on digging the issue yesterday so the main concern of the
patch is to get the tuple length from ExecFetchSlotHeapTuple().
+ ExecCopySlot(batchslot, slot);
+ tuple = ExecFetchSlotHeapTuple(batchslot, true, NULL);
+
+ myState->mi_slots_num++;
+ myState->mi_slots_size += tupl
On Mon, Sep 30, 2019 at 12:38:02AM -0700, Andres Freund wrote:
> That does not strike me as a good idea. The upper layer is going to need
> to manage some resources (e.g. it's the only bit that knows about how to
> manage lifetime of the incoming data), and by exposing it to each AM
> we're going t
Hi,
On 2019-09-30 12:12:31 +0800, Paul Guo wrote:
> > > > However, I can also see that there is no better alternative. We need
> > to
> > > > compute the size of accumulated tuples so far, in order to decide
> > whether
> > > > to stop accumulating tuples. There is no convenient way to obtain th
>
>
> > > However, I can also see that there is no better alternative. We need
> to
> > > compute the size of accumulated tuples so far, in order to decide
> whether
> > > to stop accumulating tuples. There is no convenient way to obtain the
> > > length of the tuple, given a slot. How about mak
On Sat, Sep 28, 2019 at 5:49 AM Andres Freund wrote:
> Hi,
>
> On 2019-09-09 18:31:54 +0800, Paul Guo wrote:
> > diff --git a/src/backend/access/heap/heapam.c
> b/src/backend/access/heap/heapam.c
> > index e9544822bf..8a844b3b5f 100644
> > --- a/src/backend/access/heap/heapam.c
> > +++ b/src/back
Hi,
On 2019-09-09 18:31:54 +0800, Paul Guo wrote:
> diff --git a/src/backend/access/heap/heapam.c
> b/src/backend/access/heap/heapam.c
> index e9544822bf..8a844b3b5f 100644
> --- a/src/backend/access/heap/heapam.c
> +++ b/src/backend/access/heap/heapam.c
> @@ -2106,7 +2106,6 @@ heap_multi_insert(
Hi,
On 2019-09-26 10:43:27 -0300, Alvaro Herrera wrote:
> On 2019-Sep-25, Asim R P wrote:
>
> > I reviewed your patch today. It looks good overall. My concern is that
> > the ExecFetchSlotHeapTuple call does not seem appropriate. In a generic
> > place such as createas.c, we should be using ge
On Thu, Sep 26, 2019 at 7:13 PM Alvaro Herrera
wrote:
>
> On 2019-Sep-25, Asim R P wrote:
>
> > I reviewed your patch today. It looks good overall. My concern is that
> > the ExecFetchSlotHeapTuple call does not seem appropriate. In a generic
> > place such as createas.c, we should be using gen
On Thu, Sep 26, 2019 at 9:43 PM Alvaro Herrera
wrote:
> On 2019-Sep-25, Asim R P wrote:
>
> > I reviewed your patch today. It looks good overall. My concern is that
> > the ExecFetchSlotHeapTuple call does not seem appropriate. In a generic
> > place such as createas.c, we should be using gene
Asim Thanks for the review.
On Wed, Sep 25, 2019 at 6:39 PM Asim R P wrote:
>
>
>
> On Mon, Sep 9, 2019 at 4:02 PM Paul Guo wrote:
> >
> > So in theory
> > we should not worry about additional tuple copy overhead now, and then I
> tried the patch without setting
> > multi-insert threshold as at
On 2019-Sep-25, Asim R P wrote:
> I reviewed your patch today. It looks good overall. My concern is that
> the ExecFetchSlotHeapTuple call does not seem appropriate. In a generic
> place such as createas.c, we should be using generic tableam API only.
> However, I can also see that there is no
On Mon, Sep 9, 2019 at 4:02 PM Paul Guo wrote:
>
> So in theory
> we should not worry about additional tuple copy overhead now, and then I
tried the patch without setting
> multi-insert threshold as attached.
>
I reviewed your patch today. It looks good overall. My concern is that
the ExecFetch
On Fri, Aug 2, 2019 at 2:55 AM Heikki Linnakangas wrote:
> On 17/06/2019 15:53, Paul Guo wrote:
> > I noticed that to do batch insert, we might need additional memory copy
> > sometimes comparing with "single insert"
> > (that should be the reason that we previously saw a bit regressions) so a
>
On 17/06/2019 15:53, Paul Guo wrote:
I noticed that to do batch insert, we might need additional memory copy
sometimes comparing with "single insert"
(that should be the reason that we previously saw a bit regressions) so a
good solution seems to fall back
to "single insert" if the tuple length i
On Mon, Jun 17, 2019 at 8:53 PM Paul Guo wrote:
> Hi all,
>
> I've been working other things until recently I restarted the work,
> profiling & refactoring the code.
> It's been a long time since the last patch was proposed. The new patch has
> now been firstly refactored due to
> 4da597edf1bae0c
Hi all,
I've been working other things until recently I restarted the work,
profiling & refactoring the code.
It's been a long time since the last patch was proposed. The new patch has
now been firstly refactored due to
4da597edf1bae0cf0453b5ed6fc4347b6334dfe1 (Make TupleTableSlots extensible,
fin
On Mon, Mar 11, 2019 at 2:58 AM David Fetter wrote:
> On Wed, Mar 06, 2019 at 10:06:27PM +0800, Paul Guo wrote:
> > Hello, Postgres hackers,
> >
> > The copy code has used batch insert with function heap_multi_insert() to
> > speed up. It seems that Create Table As or Materialized View could
> le
On Wed, Mar 06, 2019 at 10:06:27PM +0800, Paul Guo wrote:
> Hello, Postgres hackers,
>
> The copy code has used batch insert with function heap_multi_insert() to
> speed up. It seems that Create Table As or Materialized View could leverage
> that code also to boost the performance also. Attached i
Sorry for the late reply.
To Michael. Thank you. I know this commitfest is ongoing and I'm not
targeting for this.
On Thu, Mar 7, 2019 at 4:54 PM Heikki Linnakangas wrote:
> On 06/03/2019 22:06, Paul Guo wrote:
> > The patch also modifies heap_multi_insert() a bit to do a bit further
> > code-l
On 06/03/2019 22:06, Paul Guo wrote:
The patch also modifies heap_multi_insert() a bit to do a bit further
code-level optimization by using static memory, instead of using memory
context and dynamic allocation.
If toasting is required, heap_prepare_insert() creates a palloc'd tuple.
That is s
Hi,
On Wed, Mar 06, 2019 at 10:06:27PM +0800, Paul Guo wrote:
> The copy code has used batch insert with function heap_multi_insert() to
> speed up. It seems that Create Table As or Materialized View could leverage
> that code also to boost the performance also. Attached is a patch to
> implement
Hello, Postgres hackers,
The copy code has used batch insert with function heap_multi_insert() to
speed up. It seems that Create Table As or Materialized View could leverage
that code also to boost the performance also. Attached is a patch to
implement that. That was done by Taylor (cc-ed) and me.
27 matches
Mail list logo
