public inbox for [email protected]
help / color / mirror / Atom feed[PATCH v9 4/4] WIP: check tuple size
24+ messages / 2 participants
[nested] [flat]
* [PATCH v9 4/4] WIP: check tuple size
@ 2020-12-01 23:20 Justin Pryzby <[email protected]>
0 siblings, 0 replies; 24+ 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] 24+ messages in thread
* [PATCH v8 4/4] WIP: check tuple size
@ 2020-12-01 23:20 Justin Pryzby <[email protected]>
0 siblings, 0 replies; 24+ 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] 24+ messages in thread
* [PATCH v9 4/4] WIP: check tuple size
@ 2020-12-01 23:20 Justin Pryzby <[email protected]>
0 siblings, 0 replies; 24+ 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] 24+ messages in thread
* [PATCH v9 4/4] WIP: check tuple size
@ 2020-12-01 23:20 Justin Pryzby <[email protected]>
0 siblings, 0 replies; 24+ 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] 24+ messages in thread
* [PATCH v9 4/4] WIP: check tuple size
@ 2020-12-01 23:20 Justin Pryzby <[email protected]>
0 siblings, 0 replies; 24+ 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] 24+ messages in thread
* [PATCH v9 4/4] WIP: check tuple size
@ 2020-12-01 23:20 Justin Pryzby <[email protected]>
0 siblings, 0 replies; 24+ 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] 24+ messages in thread
* [PATCH v9 4/4] WIP: check tuple size
@ 2020-12-01 23:20 Justin Pryzby <[email protected]>
0 siblings, 0 replies; 24+ 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] 24+ messages in thread
* [PATCH v9 4/4] WIP: check tuple size
@ 2020-12-01 23:20 Justin Pryzby <[email protected]>
0 siblings, 0 replies; 24+ 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] 24+ messages in thread
* [PATCH v9 4/4] WIP: check tuple size
@ 2020-12-01 23:20 Justin Pryzby <[email protected]>
0 siblings, 0 replies; 24+ 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] 24+ messages in thread
* [PATCH v9 4/4] WIP: check tuple size
@ 2020-12-01 23:20 Justin Pryzby <[email protected]>
0 siblings, 0 replies; 24+ 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] 24+ messages in thread
* [PATCH v9 4/4] WIP: check tuple size
@ 2020-12-01 23:20 Justin Pryzby <[email protected]>
0 siblings, 0 replies; 24+ 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] 24+ messages in thread
* [PATCH v9 4/4] WIP: check tuple size
@ 2020-12-01 23:20 Justin Pryzby <[email protected]>
0 siblings, 0 replies; 24+ 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] 24+ messages in thread
* [PATCH v9 4/4] WIP: check tuple size
@ 2020-12-01 23:20 Justin Pryzby <[email protected]>
0 siblings, 0 replies; 24+ 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] 24+ messages in thread
* [PATCH v9 4/4] WIP: check tuple size
@ 2020-12-01 23:20 Justin Pryzby <[email protected]>
0 siblings, 0 replies; 24+ 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] 24+ messages in thread
* [PATCH v9 4/4] WIP: check tuple size
@ 2020-12-01 23:20 Justin Pryzby <[email protected]>
0 siblings, 0 replies; 24+ 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] 24+ messages in thread
* [PATCH v9 4/4] WIP: check tuple size
@ 2020-12-01 23:20 Justin Pryzby <[email protected]>
0 siblings, 0 replies; 24+ 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] 24+ messages in thread
* [PATCH v9 4/4] WIP: check tuple size
@ 2020-12-01 23:20 Justin Pryzby <[email protected]>
0 siblings, 0 replies; 24+ 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] 24+ messages in thread
* [PATCH v9 4/4] WIP: check tuple size
@ 2020-12-01 23:20 Justin Pryzby <[email protected]>
0 siblings, 0 replies; 24+ 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] 24+ messages in thread
* [PATCH v9 4/4] WIP: check tuple size
@ 2020-12-01 23:20 Justin Pryzby <[email protected]>
0 siblings, 0 replies; 24+ 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] 24+ messages in thread
* [PATCH v9 4/4] WIP: check tuple size
@ 2020-12-01 23:20 Justin Pryzby <[email protected]>
0 siblings, 0 replies; 24+ 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] 24+ messages in thread
* [PATCH v9 4/4] WIP: check tuple size
@ 2020-12-01 23:20 Justin Pryzby <[email protected]>
0 siblings, 0 replies; 24+ 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] 24+ messages in thread
* [PATCH v9 4/4] WIP: check tuple size
@ 2020-12-01 23:20 Justin Pryzby <[email protected]>
0 siblings, 0 replies; 24+ 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] 24+ messages in thread
* [PATCH v10 4/4] WIP: check tuple size
@ 2020-12-01 23:20 Justin Pryzby <[email protected]>
0 siblings, 0 replies; 24+ 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] 24+ messages in thread
* Re: perl 5.36, C99, -Wdeclaration-after-statement -Wshadow=compatible-local
@ 2023-01-02 23:46 Andres Freund <[email protected]>
0 siblings, 0 replies; 24+ messages in thread
From: Andres Freund @ 2023-01-02 23:46 UTC (permalink / raw)
To: Tom Lane <[email protected]>; +Cc: Peter Eisentraut <[email protected]>; pgsql-hackers; David Rowley <[email protected]>; Dagfinn Ilmari Mannsåker <[email protected]>
Hi,
On 2022-12-29 13:40:13 -0800, Andres Freund wrote:
> > > Should we backpatch this? Given the volume of warnings it's probably a good
> > > idea. But I'd let it step in HEAD for a few days of buildfarm coverage first.
> >
> > +1 to both points.
>
> Pushed to HEAD.
I haven't seen any problems in HEAD, so I'm working on backpatching.
Greetings,
Andres Freund
^ permalink raw reply [nested|flat] 24+ messages in thread
end of thread, other threads:[~2023-01-02 23:46 UTC | newest]
Thread overview: 24+ 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 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]>
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]>
2023-01-02 23:46 Re: perl 5.36, C99, -Wdeclaration-after-statement -Wshadow=compatible-local Andres Freund <[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