public inbox for [email protected]
help / color / mirror / Atom feed[PATCH v9 4/4] WIP: check tuple size
25+ messages / 3 participants
[nested] [flat]
* [PATCH v9 4/4] WIP: check tuple size
@ 2020-12-01 23:20 Justin Pryzby <[email protected]>
0 siblings, 0 replies; 25+ messages in thread
From: Justin Pryzby @ 2020-12-01 23:20 UTC (permalink / raw)
Or maybe INSERT should flush buffer based only on the *number* of tuples, and
not their size ?
---
src/backend/executor/nodeModifyTable.c | 8 +++++++-
1 file changed, 7 insertions(+), 1 deletion(-)
diff --git a/src/backend/executor/nodeModifyTable.c b/src/backend/executor/nodeModifyTable.c
index 2059428e2a..04b0598183 100644
--- a/src/backend/executor/nodeModifyTable.c
+++ b/src/backend/executor/nodeModifyTable.c
@@ -703,7 +703,13 @@ ExecInsert(ModifyTableState *mtstate,
batchslot = MultiInsertInfoNextFreeSlot(mtstate->miinfo, resultRelInfo);
ExecCopySlot(batchslot, slot);
- MultiInsertInfoStore(mtstate->miinfo, resultRelInfo, batchslot, 0, 0); // XXX: tuplen/lineno
+ MultiInsertInfoStore(mtstate->miinfo, resultRelInfo, batchslot,
+ // sizeof(void*) * batchslot->tts_nvalid, /* tuple size - underestimate */
+ MemoryContextMemAllocated(batchslot->tts_mcxt, true), /* tuple size */
+ mtstate->ntuples); /* lineno */
+
+ elog(DEBUG2, "bufferedBytes %d; tuples %ld",
+ mtstate->miinfo->bufferedBytes, mtstate->ntuples);
if (MultiInsertInfoIsFull(mtstate->miinfo))
MultiInsertInfoFlush(mtstate->miinfo, resultRelInfo);
--
2.17.0
--3yNHWXBV/QO9xKNm--
^ permalink raw reply [nested|flat] 25+ messages in thread
* [PATCH v9 4/4] WIP: check tuple size
@ 2020-12-01 23:20 Justin Pryzby <[email protected]>
0 siblings, 0 replies; 25+ messages in thread
From: Justin Pryzby @ 2020-12-01 23:20 UTC (permalink / raw)
Or maybe INSERT should flush buffer based only on the *number* of tuples, and
not their size ?
---
src/backend/executor/nodeModifyTable.c | 8 +++++++-
1 file changed, 7 insertions(+), 1 deletion(-)
diff --git a/src/backend/executor/nodeModifyTable.c b/src/backend/executor/nodeModifyTable.c
index 2059428e2a..04b0598183 100644
--- a/src/backend/executor/nodeModifyTable.c
+++ b/src/backend/executor/nodeModifyTable.c
@@ -703,7 +703,13 @@ ExecInsert(ModifyTableState *mtstate,
batchslot = MultiInsertInfoNextFreeSlot(mtstate->miinfo, resultRelInfo);
ExecCopySlot(batchslot, slot);
- MultiInsertInfoStore(mtstate->miinfo, resultRelInfo, batchslot, 0, 0); // XXX: tuplen/lineno
+ MultiInsertInfoStore(mtstate->miinfo, resultRelInfo, batchslot,
+ // sizeof(void*) * batchslot->tts_nvalid, /* tuple size - underestimate */
+ MemoryContextMemAllocated(batchslot->tts_mcxt, true), /* tuple size */
+ mtstate->ntuples); /* lineno */
+
+ elog(DEBUG2, "bufferedBytes %d; tuples %ld",
+ mtstate->miinfo->bufferedBytes, mtstate->ntuples);
if (MultiInsertInfoIsFull(mtstate->miinfo))
MultiInsertInfoFlush(mtstate->miinfo, resultRelInfo);
--
2.17.0
--3yNHWXBV/QO9xKNm--
^ permalink raw reply [nested|flat] 25+ messages in thread
* [PATCH v10 4/4] WIP: check tuple size
@ 2020-12-01 23:20 Justin Pryzby <[email protected]>
0 siblings, 0 replies; 25+ messages in thread
From: Justin Pryzby @ 2020-12-01 23:20 UTC (permalink / raw)
Or maybe INSERT should flush buffer based only on the *number* of tuples, and
not their size ?
---
src/backend/executor/nodeModifyTable.c | 8 +++++++-
1 file changed, 7 insertions(+), 1 deletion(-)
diff --git a/src/backend/executor/nodeModifyTable.c b/src/backend/executor/nodeModifyTable.c
index e018946c0e..ec9e43ac55 100644
--- a/src/backend/executor/nodeModifyTable.c
+++ b/src/backend/executor/nodeModifyTable.c
@@ -760,7 +760,13 @@ ExecInsert(ModifyTableState *mtstate,
batchslot = MultiInsertInfoNextFreeSlot(mtstate->miinfo, resultRelInfo);
ExecCopySlot(batchslot, slot);
- MultiInsertInfoStore(mtstate->miinfo, resultRelInfo, batchslot, 0, 0); // XXX: tuplen/lineno
+ MultiInsertInfoStore(mtstate->miinfo, resultRelInfo, batchslot,
+ // sizeof(void*) * batchslot->tts_nvalid, /* tuple size - underestimate */
+ MemoryContextMemAllocated(batchslot->tts_mcxt, true), /* tuple size */
+ mtstate->ntuples); /* lineno */
+
+ elog(DEBUG2, "bufferedBytes %d; tuples %ld",
+ mtstate->miinfo->bufferedBytes, mtstate->ntuples);
if (MultiInsertInfoIsFull(mtstate->miinfo))
MultiInsertInfoFlush(mtstate->miinfo, resultRelInfo);
--
2.17.0
--8nsIa27JVQLqB7/C--
^ permalink raw reply [nested|flat] 25+ messages in thread
* [PATCH v8 4/4] WIP: check tuple size
@ 2020-12-01 23:20 Justin Pryzby <[email protected]>
0 siblings, 0 replies; 25+ messages in thread
From: Justin Pryzby @ 2020-12-01 23:20 UTC (permalink / raw)
Or maybe INSERT should flush buffer based only on the *number* of tuples, and
not their size ?
---
src/backend/executor/nodeModifyTable.c | 8 +++++++-
1 file changed, 7 insertions(+), 1 deletion(-)
diff --git a/src/backend/executor/nodeModifyTable.c b/src/backend/executor/nodeModifyTable.c
index 47a5271b91..b4f523e32d 100644
--- a/src/backend/executor/nodeModifyTable.c
+++ b/src/backend/executor/nodeModifyTable.c
@@ -703,7 +703,13 @@ ExecInsert(ModifyTableState *mtstate,
batchslot = MultiInsertInfoNextFreeSlot(mtstate->miinfo, resultRelInfo);
ExecCopySlot(batchslot, slot);
- MultiInsertInfoStore(mtstate->miinfo, resultRelInfo, batchslot, 0, 0); // XXX: tuplen/lineno
+ MultiInsertInfoStore(mtstate->miinfo, resultRelInfo, batchslot,
+ // sizeof(void*) * batchslot->tts_nvalid, /* tuple size - underestimate */
+ MemoryContextMemAllocated(batchslot->tts_mcxt, true), /* tuple size */
+ mtstate->ntuples); /* lineno */
+
+ elog(DEBUG2, "bufferedBytes %d; tuples %ld",
+ mtstate->miinfo->bufferedBytes, mtstate->ntuples);
if (MultiInsertInfoIsFull(mtstate->miinfo))
MultiInsertInfoFlush(mtstate->miinfo, resultRelInfo);
--
2.17.0
--AZuoSAvZwvV/ife4--
^ permalink raw reply [nested|flat] 25+ messages in thread
* [PATCH v9 4/4] WIP: check tuple size
@ 2020-12-01 23:20 Justin Pryzby <[email protected]>
0 siblings, 0 replies; 25+ messages in thread
From: Justin Pryzby @ 2020-12-01 23:20 UTC (permalink / raw)
Or maybe INSERT should flush buffer based only on the *number* of tuples, and
not their size ?
---
src/backend/executor/nodeModifyTable.c | 8 +++++++-
1 file changed, 7 insertions(+), 1 deletion(-)
diff --git a/src/backend/executor/nodeModifyTable.c b/src/backend/executor/nodeModifyTable.c
index 2059428e2a..04b0598183 100644
--- a/src/backend/executor/nodeModifyTable.c
+++ b/src/backend/executor/nodeModifyTable.c
@@ -703,7 +703,13 @@ ExecInsert(ModifyTableState *mtstate,
batchslot = MultiInsertInfoNextFreeSlot(mtstate->miinfo, resultRelInfo);
ExecCopySlot(batchslot, slot);
- MultiInsertInfoStore(mtstate->miinfo, resultRelInfo, batchslot, 0, 0); // XXX: tuplen/lineno
+ MultiInsertInfoStore(mtstate->miinfo, resultRelInfo, batchslot,
+ // sizeof(void*) * batchslot->tts_nvalid, /* tuple size - underestimate */
+ MemoryContextMemAllocated(batchslot->tts_mcxt, true), /* tuple size */
+ mtstate->ntuples); /* lineno */
+
+ elog(DEBUG2, "bufferedBytes %d; tuples %ld",
+ mtstate->miinfo->bufferedBytes, mtstate->ntuples);
if (MultiInsertInfoIsFull(mtstate->miinfo))
MultiInsertInfoFlush(mtstate->miinfo, resultRelInfo);
--
2.17.0
--3yNHWXBV/QO9xKNm--
^ permalink raw reply [nested|flat] 25+ messages in thread
* [PATCH v9 4/4] WIP: check tuple size
@ 2020-12-01 23:20 Justin Pryzby <[email protected]>
0 siblings, 0 replies; 25+ messages in thread
From: Justin Pryzby @ 2020-12-01 23:20 UTC (permalink / raw)
Or maybe INSERT should flush buffer based only on the *number* of tuples, and
not their size ?
---
src/backend/executor/nodeModifyTable.c | 8 +++++++-
1 file changed, 7 insertions(+), 1 deletion(-)
diff --git a/src/backend/executor/nodeModifyTable.c b/src/backend/executor/nodeModifyTable.c
index 2059428e2a..04b0598183 100644
--- a/src/backend/executor/nodeModifyTable.c
+++ b/src/backend/executor/nodeModifyTable.c
@@ -703,7 +703,13 @@ ExecInsert(ModifyTableState *mtstate,
batchslot = MultiInsertInfoNextFreeSlot(mtstate->miinfo, resultRelInfo);
ExecCopySlot(batchslot, slot);
- MultiInsertInfoStore(mtstate->miinfo, resultRelInfo, batchslot, 0, 0); // XXX: tuplen/lineno
+ MultiInsertInfoStore(mtstate->miinfo, resultRelInfo, batchslot,
+ // sizeof(void*) * batchslot->tts_nvalid, /* tuple size - underestimate */
+ MemoryContextMemAllocated(batchslot->tts_mcxt, true), /* tuple size */
+ mtstate->ntuples); /* lineno */
+
+ elog(DEBUG2, "bufferedBytes %d; tuples %ld",
+ mtstate->miinfo->bufferedBytes, mtstate->ntuples);
if (MultiInsertInfoIsFull(mtstate->miinfo))
MultiInsertInfoFlush(mtstate->miinfo, resultRelInfo);
--
2.17.0
--3yNHWXBV/QO9xKNm--
^ permalink raw reply [nested|flat] 25+ messages in thread
* [PATCH v9 4/4] WIP: check tuple size
@ 2020-12-01 23:20 Justin Pryzby <[email protected]>
0 siblings, 0 replies; 25+ messages in thread
From: Justin Pryzby @ 2020-12-01 23:20 UTC (permalink / raw)
Or maybe INSERT should flush buffer based only on the *number* of tuples, and
not their size ?
---
src/backend/executor/nodeModifyTable.c | 8 +++++++-
1 file changed, 7 insertions(+), 1 deletion(-)
diff --git a/src/backend/executor/nodeModifyTable.c b/src/backend/executor/nodeModifyTable.c
index 2059428e2a..04b0598183 100644
--- a/src/backend/executor/nodeModifyTable.c
+++ b/src/backend/executor/nodeModifyTable.c
@@ -703,7 +703,13 @@ ExecInsert(ModifyTableState *mtstate,
batchslot = MultiInsertInfoNextFreeSlot(mtstate->miinfo, resultRelInfo);
ExecCopySlot(batchslot, slot);
- MultiInsertInfoStore(mtstate->miinfo, resultRelInfo, batchslot, 0, 0); // XXX: tuplen/lineno
+ MultiInsertInfoStore(mtstate->miinfo, resultRelInfo, batchslot,
+ // sizeof(void*) * batchslot->tts_nvalid, /* tuple size - underestimate */
+ MemoryContextMemAllocated(batchslot->tts_mcxt, true), /* tuple size */
+ mtstate->ntuples); /* lineno */
+
+ elog(DEBUG2, "bufferedBytes %d; tuples %ld",
+ mtstate->miinfo->bufferedBytes, mtstate->ntuples);
if (MultiInsertInfoIsFull(mtstate->miinfo))
MultiInsertInfoFlush(mtstate->miinfo, resultRelInfo);
--
2.17.0
--3yNHWXBV/QO9xKNm--
^ permalink raw reply [nested|flat] 25+ messages in thread
* [PATCH v9 4/4] WIP: check tuple size
@ 2020-12-01 23:20 Justin Pryzby <[email protected]>
0 siblings, 0 replies; 25+ messages in thread
From: Justin Pryzby @ 2020-12-01 23:20 UTC (permalink / raw)
Or maybe INSERT should flush buffer based only on the *number* of tuples, and
not their size ?
---
src/backend/executor/nodeModifyTable.c | 8 +++++++-
1 file changed, 7 insertions(+), 1 deletion(-)
diff --git a/src/backend/executor/nodeModifyTable.c b/src/backend/executor/nodeModifyTable.c
index 2059428e2a..04b0598183 100644
--- a/src/backend/executor/nodeModifyTable.c
+++ b/src/backend/executor/nodeModifyTable.c
@@ -703,7 +703,13 @@ ExecInsert(ModifyTableState *mtstate,
batchslot = MultiInsertInfoNextFreeSlot(mtstate->miinfo, resultRelInfo);
ExecCopySlot(batchslot, slot);
- MultiInsertInfoStore(mtstate->miinfo, resultRelInfo, batchslot, 0, 0); // XXX: tuplen/lineno
+ MultiInsertInfoStore(mtstate->miinfo, resultRelInfo, batchslot,
+ // sizeof(void*) * batchslot->tts_nvalid, /* tuple size - underestimate */
+ MemoryContextMemAllocated(batchslot->tts_mcxt, true), /* tuple size */
+ mtstate->ntuples); /* lineno */
+
+ elog(DEBUG2, "bufferedBytes %d; tuples %ld",
+ mtstate->miinfo->bufferedBytes, mtstate->ntuples);
if (MultiInsertInfoIsFull(mtstate->miinfo))
MultiInsertInfoFlush(mtstate->miinfo, resultRelInfo);
--
2.17.0
--3yNHWXBV/QO9xKNm--
^ permalink raw reply [nested|flat] 25+ messages in thread
* [PATCH v9 4/4] WIP: check tuple size
@ 2020-12-01 23:20 Justin Pryzby <[email protected]>
0 siblings, 0 replies; 25+ messages in thread
From: Justin Pryzby @ 2020-12-01 23:20 UTC (permalink / raw)
Or maybe INSERT should flush buffer based only on the *number* of tuples, and
not their size ?
---
src/backend/executor/nodeModifyTable.c | 8 +++++++-
1 file changed, 7 insertions(+), 1 deletion(-)
diff --git a/src/backend/executor/nodeModifyTable.c b/src/backend/executor/nodeModifyTable.c
index 2059428e2a..04b0598183 100644
--- a/src/backend/executor/nodeModifyTable.c
+++ b/src/backend/executor/nodeModifyTable.c
@@ -703,7 +703,13 @@ ExecInsert(ModifyTableState *mtstate,
batchslot = MultiInsertInfoNextFreeSlot(mtstate->miinfo, resultRelInfo);
ExecCopySlot(batchslot, slot);
- MultiInsertInfoStore(mtstate->miinfo, resultRelInfo, batchslot, 0, 0); // XXX: tuplen/lineno
+ MultiInsertInfoStore(mtstate->miinfo, resultRelInfo, batchslot,
+ // sizeof(void*) * batchslot->tts_nvalid, /* tuple size - underestimate */
+ MemoryContextMemAllocated(batchslot->tts_mcxt, true), /* tuple size */
+ mtstate->ntuples); /* lineno */
+
+ elog(DEBUG2, "bufferedBytes %d; tuples %ld",
+ mtstate->miinfo->bufferedBytes, mtstate->ntuples);
if (MultiInsertInfoIsFull(mtstate->miinfo))
MultiInsertInfoFlush(mtstate->miinfo, resultRelInfo);
--
2.17.0
--3yNHWXBV/QO9xKNm--
^ permalink raw reply [nested|flat] 25+ messages in thread
* [PATCH v9 4/4] WIP: check tuple size
@ 2020-12-01 23:20 Justin Pryzby <[email protected]>
0 siblings, 0 replies; 25+ messages in thread
From: Justin Pryzby @ 2020-12-01 23:20 UTC (permalink / raw)
Or maybe INSERT should flush buffer based only on the *number* of tuples, and
not their size ?
---
src/backend/executor/nodeModifyTable.c | 8 +++++++-
1 file changed, 7 insertions(+), 1 deletion(-)
diff --git a/src/backend/executor/nodeModifyTable.c b/src/backend/executor/nodeModifyTable.c
index 2059428e2a..04b0598183 100644
--- a/src/backend/executor/nodeModifyTable.c
+++ b/src/backend/executor/nodeModifyTable.c
@@ -703,7 +703,13 @@ ExecInsert(ModifyTableState *mtstate,
batchslot = MultiInsertInfoNextFreeSlot(mtstate->miinfo, resultRelInfo);
ExecCopySlot(batchslot, slot);
- MultiInsertInfoStore(mtstate->miinfo, resultRelInfo, batchslot, 0, 0); // XXX: tuplen/lineno
+ MultiInsertInfoStore(mtstate->miinfo, resultRelInfo, batchslot,
+ // sizeof(void*) * batchslot->tts_nvalid, /* tuple size - underestimate */
+ MemoryContextMemAllocated(batchslot->tts_mcxt, true), /* tuple size */
+ mtstate->ntuples); /* lineno */
+
+ elog(DEBUG2, "bufferedBytes %d; tuples %ld",
+ mtstate->miinfo->bufferedBytes, mtstate->ntuples);
if (MultiInsertInfoIsFull(mtstate->miinfo))
MultiInsertInfoFlush(mtstate->miinfo, resultRelInfo);
--
2.17.0
--3yNHWXBV/QO9xKNm--
^ permalink raw reply [nested|flat] 25+ messages in thread
* [PATCH v9 4/4] WIP: check tuple size
@ 2020-12-01 23:20 Justin Pryzby <[email protected]>
0 siblings, 0 replies; 25+ messages in thread
From: Justin Pryzby @ 2020-12-01 23:20 UTC (permalink / raw)
Or maybe INSERT should flush buffer based only on the *number* of tuples, and
not their size ?
---
src/backend/executor/nodeModifyTable.c | 8 +++++++-
1 file changed, 7 insertions(+), 1 deletion(-)
diff --git a/src/backend/executor/nodeModifyTable.c b/src/backend/executor/nodeModifyTable.c
index 2059428e2a..04b0598183 100644
--- a/src/backend/executor/nodeModifyTable.c
+++ b/src/backend/executor/nodeModifyTable.c
@@ -703,7 +703,13 @@ ExecInsert(ModifyTableState *mtstate,
batchslot = MultiInsertInfoNextFreeSlot(mtstate->miinfo, resultRelInfo);
ExecCopySlot(batchslot, slot);
- MultiInsertInfoStore(mtstate->miinfo, resultRelInfo, batchslot, 0, 0); // XXX: tuplen/lineno
+ MultiInsertInfoStore(mtstate->miinfo, resultRelInfo, batchslot,
+ // sizeof(void*) * batchslot->tts_nvalid, /* tuple size - underestimate */
+ MemoryContextMemAllocated(batchslot->tts_mcxt, true), /* tuple size */
+ mtstate->ntuples); /* lineno */
+
+ elog(DEBUG2, "bufferedBytes %d; tuples %ld",
+ mtstate->miinfo->bufferedBytes, mtstate->ntuples);
if (MultiInsertInfoIsFull(mtstate->miinfo))
MultiInsertInfoFlush(mtstate->miinfo, resultRelInfo);
--
2.17.0
--3yNHWXBV/QO9xKNm--
^ permalink raw reply [nested|flat] 25+ messages in thread
* [PATCH v9 4/4] WIP: check tuple size
@ 2020-12-01 23:20 Justin Pryzby <[email protected]>
0 siblings, 0 replies; 25+ messages in thread
From: Justin Pryzby @ 2020-12-01 23:20 UTC (permalink / raw)
Or maybe INSERT should flush buffer based only on the *number* of tuples, and
not their size ?
---
src/backend/executor/nodeModifyTable.c | 8 +++++++-
1 file changed, 7 insertions(+), 1 deletion(-)
diff --git a/src/backend/executor/nodeModifyTable.c b/src/backend/executor/nodeModifyTable.c
index 2059428e2a..04b0598183 100644
--- a/src/backend/executor/nodeModifyTable.c
+++ b/src/backend/executor/nodeModifyTable.c
@@ -703,7 +703,13 @@ ExecInsert(ModifyTableState *mtstate,
batchslot = MultiInsertInfoNextFreeSlot(mtstate->miinfo, resultRelInfo);
ExecCopySlot(batchslot, slot);
- MultiInsertInfoStore(mtstate->miinfo, resultRelInfo, batchslot, 0, 0); // XXX: tuplen/lineno
+ MultiInsertInfoStore(mtstate->miinfo, resultRelInfo, batchslot,
+ // sizeof(void*) * batchslot->tts_nvalid, /* tuple size - underestimate */
+ MemoryContextMemAllocated(batchslot->tts_mcxt, true), /* tuple size */
+ mtstate->ntuples); /* lineno */
+
+ elog(DEBUG2, "bufferedBytes %d; tuples %ld",
+ mtstate->miinfo->bufferedBytes, mtstate->ntuples);
if (MultiInsertInfoIsFull(mtstate->miinfo))
MultiInsertInfoFlush(mtstate->miinfo, resultRelInfo);
--
2.17.0
--3yNHWXBV/QO9xKNm--
^ permalink raw reply [nested|flat] 25+ messages in thread
* [PATCH v9 4/4] WIP: check tuple size
@ 2020-12-01 23:20 Justin Pryzby <[email protected]>
0 siblings, 0 replies; 25+ messages in thread
From: Justin Pryzby @ 2020-12-01 23:20 UTC (permalink / raw)
Or maybe INSERT should flush buffer based only on the *number* of tuples, and
not their size ?
---
src/backend/executor/nodeModifyTable.c | 8 +++++++-
1 file changed, 7 insertions(+), 1 deletion(-)
diff --git a/src/backend/executor/nodeModifyTable.c b/src/backend/executor/nodeModifyTable.c
index 2059428e2a..04b0598183 100644
--- a/src/backend/executor/nodeModifyTable.c
+++ b/src/backend/executor/nodeModifyTable.c
@@ -703,7 +703,13 @@ ExecInsert(ModifyTableState *mtstate,
batchslot = MultiInsertInfoNextFreeSlot(mtstate->miinfo, resultRelInfo);
ExecCopySlot(batchslot, slot);
- MultiInsertInfoStore(mtstate->miinfo, resultRelInfo, batchslot, 0, 0); // XXX: tuplen/lineno
+ MultiInsertInfoStore(mtstate->miinfo, resultRelInfo, batchslot,
+ // sizeof(void*) * batchslot->tts_nvalid, /* tuple size - underestimate */
+ MemoryContextMemAllocated(batchslot->tts_mcxt, true), /* tuple size */
+ mtstate->ntuples); /* lineno */
+
+ elog(DEBUG2, "bufferedBytes %d; tuples %ld",
+ mtstate->miinfo->bufferedBytes, mtstate->ntuples);
if (MultiInsertInfoIsFull(mtstate->miinfo))
MultiInsertInfoFlush(mtstate->miinfo, resultRelInfo);
--
2.17.0
--3yNHWXBV/QO9xKNm--
^ permalink raw reply [nested|flat] 25+ messages in thread
* [PATCH v9 4/4] WIP: check tuple size
@ 2020-12-01 23:20 Justin Pryzby <[email protected]>
0 siblings, 0 replies; 25+ messages in thread
From: Justin Pryzby @ 2020-12-01 23:20 UTC (permalink / raw)
Or maybe INSERT should flush buffer based only on the *number* of tuples, and
not their size ?
---
src/backend/executor/nodeModifyTable.c | 8 +++++++-
1 file changed, 7 insertions(+), 1 deletion(-)
diff --git a/src/backend/executor/nodeModifyTable.c b/src/backend/executor/nodeModifyTable.c
index 2059428e2a..04b0598183 100644
--- a/src/backend/executor/nodeModifyTable.c
+++ b/src/backend/executor/nodeModifyTable.c
@@ -703,7 +703,13 @@ ExecInsert(ModifyTableState *mtstate,
batchslot = MultiInsertInfoNextFreeSlot(mtstate->miinfo, resultRelInfo);
ExecCopySlot(batchslot, slot);
- MultiInsertInfoStore(mtstate->miinfo, resultRelInfo, batchslot, 0, 0); // XXX: tuplen/lineno
+ MultiInsertInfoStore(mtstate->miinfo, resultRelInfo, batchslot,
+ // sizeof(void*) * batchslot->tts_nvalid, /* tuple size - underestimate */
+ MemoryContextMemAllocated(batchslot->tts_mcxt, true), /* tuple size */
+ mtstate->ntuples); /* lineno */
+
+ elog(DEBUG2, "bufferedBytes %d; tuples %ld",
+ mtstate->miinfo->bufferedBytes, mtstate->ntuples);
if (MultiInsertInfoIsFull(mtstate->miinfo))
MultiInsertInfoFlush(mtstate->miinfo, resultRelInfo);
--
2.17.0
--3yNHWXBV/QO9xKNm--
^ permalink raw reply [nested|flat] 25+ messages in thread
* [PATCH v9 4/4] WIP: check tuple size
@ 2020-12-01 23:20 Justin Pryzby <[email protected]>
0 siblings, 0 replies; 25+ messages in thread
From: Justin Pryzby @ 2020-12-01 23:20 UTC (permalink / raw)
Or maybe INSERT should flush buffer based only on the *number* of tuples, and
not their size ?
---
src/backend/executor/nodeModifyTable.c | 8 +++++++-
1 file changed, 7 insertions(+), 1 deletion(-)
diff --git a/src/backend/executor/nodeModifyTable.c b/src/backend/executor/nodeModifyTable.c
index 2059428e2a..04b0598183 100644
--- a/src/backend/executor/nodeModifyTable.c
+++ b/src/backend/executor/nodeModifyTable.c
@@ -703,7 +703,13 @@ ExecInsert(ModifyTableState *mtstate,
batchslot = MultiInsertInfoNextFreeSlot(mtstate->miinfo, resultRelInfo);
ExecCopySlot(batchslot, slot);
- MultiInsertInfoStore(mtstate->miinfo, resultRelInfo, batchslot, 0, 0); // XXX: tuplen/lineno
+ MultiInsertInfoStore(mtstate->miinfo, resultRelInfo, batchslot,
+ // sizeof(void*) * batchslot->tts_nvalid, /* tuple size - underestimate */
+ MemoryContextMemAllocated(batchslot->tts_mcxt, true), /* tuple size */
+ mtstate->ntuples); /* lineno */
+
+ elog(DEBUG2, "bufferedBytes %d; tuples %ld",
+ mtstate->miinfo->bufferedBytes, mtstate->ntuples);
if (MultiInsertInfoIsFull(mtstate->miinfo))
MultiInsertInfoFlush(mtstate->miinfo, resultRelInfo);
--
2.17.0
--3yNHWXBV/QO9xKNm--
^ permalink raw reply [nested|flat] 25+ messages in thread
* [PATCH v9 4/4] WIP: check tuple size
@ 2020-12-01 23:20 Justin Pryzby <[email protected]>
0 siblings, 0 replies; 25+ messages in thread
From: Justin Pryzby @ 2020-12-01 23:20 UTC (permalink / raw)
Or maybe INSERT should flush buffer based only on the *number* of tuples, and
not their size ?
---
src/backend/executor/nodeModifyTable.c | 8 +++++++-
1 file changed, 7 insertions(+), 1 deletion(-)
diff --git a/src/backend/executor/nodeModifyTable.c b/src/backend/executor/nodeModifyTable.c
index 2059428e2a..04b0598183 100644
--- a/src/backend/executor/nodeModifyTable.c
+++ b/src/backend/executor/nodeModifyTable.c
@@ -703,7 +703,13 @@ ExecInsert(ModifyTableState *mtstate,
batchslot = MultiInsertInfoNextFreeSlot(mtstate->miinfo, resultRelInfo);
ExecCopySlot(batchslot, slot);
- MultiInsertInfoStore(mtstate->miinfo, resultRelInfo, batchslot, 0, 0); // XXX: tuplen/lineno
+ MultiInsertInfoStore(mtstate->miinfo, resultRelInfo, batchslot,
+ // sizeof(void*) * batchslot->tts_nvalid, /* tuple size - underestimate */
+ MemoryContextMemAllocated(batchslot->tts_mcxt, true), /* tuple size */
+ mtstate->ntuples); /* lineno */
+
+ elog(DEBUG2, "bufferedBytes %d; tuples %ld",
+ mtstate->miinfo->bufferedBytes, mtstate->ntuples);
if (MultiInsertInfoIsFull(mtstate->miinfo))
MultiInsertInfoFlush(mtstate->miinfo, resultRelInfo);
--
2.17.0
--3yNHWXBV/QO9xKNm--
^ permalink raw reply [nested|flat] 25+ messages in thread
* [PATCH v9 4/4] WIP: check tuple size
@ 2020-12-01 23:20 Justin Pryzby <[email protected]>
0 siblings, 0 replies; 25+ messages in thread
From: Justin Pryzby @ 2020-12-01 23:20 UTC (permalink / raw)
Or maybe INSERT should flush buffer based only on the *number* of tuples, and
not their size ?
---
src/backend/executor/nodeModifyTable.c | 8 +++++++-
1 file changed, 7 insertions(+), 1 deletion(-)
diff --git a/src/backend/executor/nodeModifyTable.c b/src/backend/executor/nodeModifyTable.c
index 2059428e2a..04b0598183 100644
--- a/src/backend/executor/nodeModifyTable.c
+++ b/src/backend/executor/nodeModifyTable.c
@@ -703,7 +703,13 @@ ExecInsert(ModifyTableState *mtstate,
batchslot = MultiInsertInfoNextFreeSlot(mtstate->miinfo, resultRelInfo);
ExecCopySlot(batchslot, slot);
- MultiInsertInfoStore(mtstate->miinfo, resultRelInfo, batchslot, 0, 0); // XXX: tuplen/lineno
+ MultiInsertInfoStore(mtstate->miinfo, resultRelInfo, batchslot,
+ // sizeof(void*) * batchslot->tts_nvalid, /* tuple size - underestimate */
+ MemoryContextMemAllocated(batchslot->tts_mcxt, true), /* tuple size */
+ mtstate->ntuples); /* lineno */
+
+ elog(DEBUG2, "bufferedBytes %d; tuples %ld",
+ mtstate->miinfo->bufferedBytes, mtstate->ntuples);
if (MultiInsertInfoIsFull(mtstate->miinfo))
MultiInsertInfoFlush(mtstate->miinfo, resultRelInfo);
--
2.17.0
--3yNHWXBV/QO9xKNm--
^ permalink raw reply [nested|flat] 25+ messages in thread
* [PATCH v9 4/4] WIP: check tuple size
@ 2020-12-01 23:20 Justin Pryzby <[email protected]>
0 siblings, 0 replies; 25+ messages in thread
From: Justin Pryzby @ 2020-12-01 23:20 UTC (permalink / raw)
Or maybe INSERT should flush buffer based only on the *number* of tuples, and
not their size ?
---
src/backend/executor/nodeModifyTable.c | 8 +++++++-
1 file changed, 7 insertions(+), 1 deletion(-)
diff --git a/src/backend/executor/nodeModifyTable.c b/src/backend/executor/nodeModifyTable.c
index 2059428e2a..04b0598183 100644
--- a/src/backend/executor/nodeModifyTable.c
+++ b/src/backend/executor/nodeModifyTable.c
@@ -703,7 +703,13 @@ ExecInsert(ModifyTableState *mtstate,
batchslot = MultiInsertInfoNextFreeSlot(mtstate->miinfo, resultRelInfo);
ExecCopySlot(batchslot, slot);
- MultiInsertInfoStore(mtstate->miinfo, resultRelInfo, batchslot, 0, 0); // XXX: tuplen/lineno
+ MultiInsertInfoStore(mtstate->miinfo, resultRelInfo, batchslot,
+ // sizeof(void*) * batchslot->tts_nvalid, /* tuple size - underestimate */
+ MemoryContextMemAllocated(batchslot->tts_mcxt, true), /* tuple size */
+ mtstate->ntuples); /* lineno */
+
+ elog(DEBUG2, "bufferedBytes %d; tuples %ld",
+ mtstate->miinfo->bufferedBytes, mtstate->ntuples);
if (MultiInsertInfoIsFull(mtstate->miinfo))
MultiInsertInfoFlush(mtstate->miinfo, resultRelInfo);
--
2.17.0
--3yNHWXBV/QO9xKNm--
^ permalink raw reply [nested|flat] 25+ messages in thread
* [PATCH v9 4/4] WIP: check tuple size
@ 2020-12-01 23:20 Justin Pryzby <[email protected]>
0 siblings, 0 replies; 25+ messages in thread
From: Justin Pryzby @ 2020-12-01 23:20 UTC (permalink / raw)
Or maybe INSERT should flush buffer based only on the *number* of tuples, and
not their size ?
---
src/backend/executor/nodeModifyTable.c | 8 +++++++-
1 file changed, 7 insertions(+), 1 deletion(-)
diff --git a/src/backend/executor/nodeModifyTable.c b/src/backend/executor/nodeModifyTable.c
index 2059428e2a..04b0598183 100644
--- a/src/backend/executor/nodeModifyTable.c
+++ b/src/backend/executor/nodeModifyTable.c
@@ -703,7 +703,13 @@ ExecInsert(ModifyTableState *mtstate,
batchslot = MultiInsertInfoNextFreeSlot(mtstate->miinfo, resultRelInfo);
ExecCopySlot(batchslot, slot);
- MultiInsertInfoStore(mtstate->miinfo, resultRelInfo, batchslot, 0, 0); // XXX: tuplen/lineno
+ MultiInsertInfoStore(mtstate->miinfo, resultRelInfo, batchslot,
+ // sizeof(void*) * batchslot->tts_nvalid, /* tuple size - underestimate */
+ MemoryContextMemAllocated(batchslot->tts_mcxt, true), /* tuple size */
+ mtstate->ntuples); /* lineno */
+
+ elog(DEBUG2, "bufferedBytes %d; tuples %ld",
+ mtstate->miinfo->bufferedBytes, mtstate->ntuples);
if (MultiInsertInfoIsFull(mtstate->miinfo))
MultiInsertInfoFlush(mtstate->miinfo, resultRelInfo);
--
2.17.0
--3yNHWXBV/QO9xKNm--
^ permalink raw reply [nested|flat] 25+ messages in thread
* [PATCH v9 4/4] WIP: check tuple size
@ 2020-12-01 23:20 Justin Pryzby <[email protected]>
0 siblings, 0 replies; 25+ messages in thread
From: Justin Pryzby @ 2020-12-01 23:20 UTC (permalink / raw)
Or maybe INSERT should flush buffer based only on the *number* of tuples, and
not their size ?
---
src/backend/executor/nodeModifyTable.c | 8 +++++++-
1 file changed, 7 insertions(+), 1 deletion(-)
diff --git a/src/backend/executor/nodeModifyTable.c b/src/backend/executor/nodeModifyTable.c
index 2059428e2a..04b0598183 100644
--- a/src/backend/executor/nodeModifyTable.c
+++ b/src/backend/executor/nodeModifyTable.c
@@ -703,7 +703,13 @@ ExecInsert(ModifyTableState *mtstate,
batchslot = MultiInsertInfoNextFreeSlot(mtstate->miinfo, resultRelInfo);
ExecCopySlot(batchslot, slot);
- MultiInsertInfoStore(mtstate->miinfo, resultRelInfo, batchslot, 0, 0); // XXX: tuplen/lineno
+ MultiInsertInfoStore(mtstate->miinfo, resultRelInfo, batchslot,
+ // sizeof(void*) * batchslot->tts_nvalid, /* tuple size - underestimate */
+ MemoryContextMemAllocated(batchslot->tts_mcxt, true), /* tuple size */
+ mtstate->ntuples); /* lineno */
+
+ elog(DEBUG2, "bufferedBytes %d; tuples %ld",
+ mtstate->miinfo->bufferedBytes, mtstate->ntuples);
if (MultiInsertInfoIsFull(mtstate->miinfo))
MultiInsertInfoFlush(mtstate->miinfo, resultRelInfo);
--
2.17.0
--3yNHWXBV/QO9xKNm--
^ permalink raw reply [nested|flat] 25+ messages in thread
* [PATCH v9 4/4] WIP: check tuple size
@ 2020-12-01 23:20 Justin Pryzby <[email protected]>
0 siblings, 0 replies; 25+ messages in thread
From: Justin Pryzby @ 2020-12-01 23:20 UTC (permalink / raw)
Or maybe INSERT should flush buffer based only on the *number* of tuples, and
not their size ?
---
src/backend/executor/nodeModifyTable.c | 8 +++++++-
1 file changed, 7 insertions(+), 1 deletion(-)
diff --git a/src/backend/executor/nodeModifyTable.c b/src/backend/executor/nodeModifyTable.c
index 2059428e2a..04b0598183 100644
--- a/src/backend/executor/nodeModifyTable.c
+++ b/src/backend/executor/nodeModifyTable.c
@@ -703,7 +703,13 @@ ExecInsert(ModifyTableState *mtstate,
batchslot = MultiInsertInfoNextFreeSlot(mtstate->miinfo, resultRelInfo);
ExecCopySlot(batchslot, slot);
- MultiInsertInfoStore(mtstate->miinfo, resultRelInfo, batchslot, 0, 0); // XXX: tuplen/lineno
+ MultiInsertInfoStore(mtstate->miinfo, resultRelInfo, batchslot,
+ // sizeof(void*) * batchslot->tts_nvalid, /* tuple size - underestimate */
+ MemoryContextMemAllocated(batchslot->tts_mcxt, true), /* tuple size */
+ mtstate->ntuples); /* lineno */
+
+ elog(DEBUG2, "bufferedBytes %d; tuples %ld",
+ mtstate->miinfo->bufferedBytes, mtstate->ntuples);
if (MultiInsertInfoIsFull(mtstate->miinfo))
MultiInsertInfoFlush(mtstate->miinfo, resultRelInfo);
--
2.17.0
--3yNHWXBV/QO9xKNm--
^ permalink raw reply [nested|flat] 25+ messages in thread
* [PATCH v9 4/4] WIP: check tuple size
@ 2020-12-01 23:20 Justin Pryzby <[email protected]>
0 siblings, 0 replies; 25+ messages in thread
From: Justin Pryzby @ 2020-12-01 23:20 UTC (permalink / raw)
Or maybe INSERT should flush buffer based only on the *number* of tuples, and
not their size ?
---
src/backend/executor/nodeModifyTable.c | 8 +++++++-
1 file changed, 7 insertions(+), 1 deletion(-)
diff --git a/src/backend/executor/nodeModifyTable.c b/src/backend/executor/nodeModifyTable.c
index 2059428e2a..04b0598183 100644
--- a/src/backend/executor/nodeModifyTable.c
+++ b/src/backend/executor/nodeModifyTable.c
@@ -703,7 +703,13 @@ ExecInsert(ModifyTableState *mtstate,
batchslot = MultiInsertInfoNextFreeSlot(mtstate->miinfo, resultRelInfo);
ExecCopySlot(batchslot, slot);
- MultiInsertInfoStore(mtstate->miinfo, resultRelInfo, batchslot, 0, 0); // XXX: tuplen/lineno
+ MultiInsertInfoStore(mtstate->miinfo, resultRelInfo, batchslot,
+ // sizeof(void*) * batchslot->tts_nvalid, /* tuple size - underestimate */
+ MemoryContextMemAllocated(batchslot->tts_mcxt, true), /* tuple size */
+ mtstate->ntuples); /* lineno */
+
+ elog(DEBUG2, "bufferedBytes %d; tuples %ld",
+ mtstate->miinfo->bufferedBytes, mtstate->ntuples);
if (MultiInsertInfoIsFull(mtstate->miinfo))
MultiInsertInfoFlush(mtstate->miinfo, resultRelInfo);
--
2.17.0
--3yNHWXBV/QO9xKNm--
^ permalink raw reply [nested|flat] 25+ messages in thread
* [PATCH v9 4/4] WIP: check tuple size
@ 2020-12-01 23:20 Justin Pryzby <[email protected]>
0 siblings, 0 replies; 25+ messages in thread
From: Justin Pryzby @ 2020-12-01 23:20 UTC (permalink / raw)
Or maybe INSERT should flush buffer based only on the *number* of tuples, and
not their size ?
---
src/backend/executor/nodeModifyTable.c | 8 +++++++-
1 file changed, 7 insertions(+), 1 deletion(-)
diff --git a/src/backend/executor/nodeModifyTable.c b/src/backend/executor/nodeModifyTable.c
index 2059428e2a..04b0598183 100644
--- a/src/backend/executor/nodeModifyTable.c
+++ b/src/backend/executor/nodeModifyTable.c
@@ -703,7 +703,13 @@ ExecInsert(ModifyTableState *mtstate,
batchslot = MultiInsertInfoNextFreeSlot(mtstate->miinfo, resultRelInfo);
ExecCopySlot(batchslot, slot);
- MultiInsertInfoStore(mtstate->miinfo, resultRelInfo, batchslot, 0, 0); // XXX: tuplen/lineno
+ MultiInsertInfoStore(mtstate->miinfo, resultRelInfo, batchslot,
+ // sizeof(void*) * batchslot->tts_nvalid, /* tuple size - underestimate */
+ MemoryContextMemAllocated(batchslot->tts_mcxt, true), /* tuple size */
+ mtstate->ntuples); /* lineno */
+
+ elog(DEBUG2, "bufferedBytes %d; tuples %ld",
+ mtstate->miinfo->bufferedBytes, mtstate->ntuples);
if (MultiInsertInfoIsFull(mtstate->miinfo))
MultiInsertInfoFlush(mtstate->miinfo, resultRelInfo);
--
2.17.0
--3yNHWXBV/QO9xKNm--
^ permalink raw reply [nested|flat] 25+ messages in thread
* Re: Get rid of PgStat_BackendFunctionEntry
@ 2023-03-16 05:25 Michael Paquier <[email protected]>
0 siblings, 1 reply; 25+ messages in thread
From: Michael Paquier @ 2023-03-16 05:25 UTC (permalink / raw)
To: Nathan Bossart <[email protected]>; +Cc: Drouvot, Bertrand <[email protected]>; PostgreSQL Hackers <[email protected]>
On Wed, Mar 08, 2023 at 01:38:38PM -0800, Nathan Bossart wrote:
> Looks reasonable to me.
I have been catching up with this thread and the other thread, and
indeed it looks like this is going to help in refactoring
pgstatfuncs.c to have more macros for all these mostly-duplicated
functions. So, I have applied this bit.
--
Michael
Attachments:
[application/pgp-signature] signature.asc (833B, ../../[email protected]/2-signature.asc)
download
^ permalink raw reply [nested|flat] 25+ messages in thread
* Re: Get rid of PgStat_BackendFunctionEntry
@ 2023-03-16 09:25 Drouvot, Bertrand <[email protected]>
parent: Michael Paquier <[email protected]>
0 siblings, 0 replies; 25+ messages in thread
From: Drouvot, Bertrand @ 2023-03-16 09:25 UTC (permalink / raw)
To: Michael Paquier <[email protected]>; Nathan Bossart <[email protected]>; +Cc: PostgreSQL Hackers <[email protected]>
Hi,
On 3/16/23 6:25 AM, Michael Paquier wrote:
> On Wed, Mar 08, 2023 at 01:38:38PM -0800, Nathan Bossart wrote:
>> Looks reasonable to me.
>
> I have been catching up with this thread and the other thread, and
> indeed it looks like this is going to help in refactoring
> pgstatfuncs.c to have more macros for all these mostly-duplicated
> functions. So, I have applied this bit.
Thanks!
Regards,
--
Bertrand Drouvot
PostgreSQL Contributors Team
RDS Open Source Databases
Amazon Web Services: https://aws.amazon.com
^ permalink raw reply [nested|flat] 25+ messages in thread
end of thread, other threads:[~2023-03-16 09:25 UTC | newest]
Thread overview: 25+ messages (download: mbox mbox.gz follow: Atom feed)
-- links below jump to the message on this page --
2020-12-01 23:20 [PATCH v9 4/4] WIP: check tuple size Justin Pryzby <[email protected]>
2020-12-01 23:20 [PATCH v9 4/4] WIP: check tuple size Justin Pryzby <[email protected]>
2020-12-01 23:20 [PATCH v9 4/4] WIP: check tuple size Justin Pryzby <[email protected]>
2020-12-01 23:20 [PATCH v9 4/4] WIP: check tuple size Justin Pryzby <[email protected]>
2020-12-01 23:20 [PATCH v9 4/4] WIP: check tuple size Justin Pryzby <[email protected]>
2020-12-01 23:20 [PATCH v8 4/4] WIP: check tuple size Justin Pryzby <[email protected]>
2020-12-01 23:20 [PATCH v9 4/4] WIP: check tuple size Justin Pryzby <[email protected]>
2020-12-01 23:20 [PATCH v9 4/4] WIP: check tuple size Justin Pryzby <[email protected]>
2020-12-01 23:20 [PATCH v9 4/4] WIP: check tuple size Justin Pryzby <[email protected]>
2020-12-01 23:20 [PATCH v9 4/4] WIP: check tuple size Justin Pryzby <[email protected]>
2020-12-01 23:20 [PATCH v9 4/4] WIP: check tuple size Justin Pryzby <[email protected]>
2020-12-01 23:20 [PATCH v9 4/4] WIP: check tuple size Justin Pryzby <[email protected]>
2020-12-01 23:20 [PATCH v9 4/4] WIP: check tuple size Justin Pryzby <[email protected]>
2020-12-01 23:20 [PATCH v9 4/4] WIP: check tuple size Justin Pryzby <[email protected]>
2020-12-01 23:20 [PATCH v9 4/4] WIP: check tuple size Justin Pryzby <[email protected]>
2020-12-01 23:20 [PATCH v9 4/4] WIP: check tuple size Justin Pryzby <[email protected]>
2020-12-01 23:20 [PATCH v9 4/4] WIP: check tuple size Justin Pryzby <[email protected]>
2020-12-01 23:20 [PATCH v9 4/4] WIP: check tuple size Justin Pryzby <[email protected]>
2020-12-01 23:20 [PATCH v10 4/4] WIP: check tuple size Justin Pryzby <[email protected]>
2020-12-01 23:20 [PATCH v9 4/4] WIP: check tuple size Justin Pryzby <[email protected]>
2020-12-01 23:20 [PATCH v9 4/4] WIP: check tuple size Justin Pryzby <[email protected]>
2020-12-01 23:20 [PATCH v9 4/4] WIP: check tuple size Justin Pryzby <[email protected]>
2020-12-01 23:20 [PATCH v9 4/4] WIP: check tuple size Justin Pryzby <[email protected]>
2023-03-16 05:25 Re: Get rid of PgStat_BackendFunctionEntry Michael Paquier <[email protected]>
2023-03-16 09:25 ` Re: Get rid of PgStat_BackendFunctionEntry Drouvot, Bertrand <[email protected]>
This inbox is served by agora; see mirroring instructions
for how to clone and mirror all data and code used for this inbox