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: psql: Add role's membership options to the \du+ command @ 2023-04-14 07:28 Kyotaro Horiguchi <[email protected]> 0 siblings, 0 replies; 24+ messages in thread From: Kyotaro Horiguchi @ 2023-04-14 07:28 UTC (permalink / raw) To: [email protected]; +Cc: [email protected]; [email protected]; [email protected]; [email protected]; [email protected] Sorry for joining in late.. At Thu, 13 Apr 2023 15:44:20 +0300, Pavel Luzanov <[email protected]> wrote in > After playing with the \du command, I found that we can't avoid > translation. > All attributes are translatable. Also, two of nine attributes shows in > new line separated format (connection limit and password valid until). Going a bit off-topic here, but I'd like the "infinity" to be translatable... As David-G appears to express concern in upthread, I don't think a direct Japanese translation from "rolename from rolename" works well, as the "from" needs accompanying verb. I, as a Japanese speaker, I prefer a more non-sentence-like notation, similar to David's suggestion but with slight differences: "pg_read_all_stats (grantor: postgres, inherit, set)" This is easily translated into Japanese. "pg_read_all_stats (付与者: postgres、継承、設定)" Come to think of this, I recalled a past discussion in which we concluded that translating punctuation marks appearing between a variable number of items within list expressions should be avoided... Thus, I'd like to propose to use an ACL-like notation, which doesn't need translation. ..| Mamber of | ..| pg_read_server_files=ais/horiguti,pg_execute_server_program=/postgres | If we'd like, but not likely, we might want to provide a parallel function to aclexplode for this notation. =# select memberofexplode('pg_read_server_files=ais/horiguti,pg_execute_server_program=/postgres'); privilege | grantor | admin | inherit | set ---------------------------+----------+-------+---------+------- pg_read_server_files | horiguti | true | true | true pg_execute_server_programs | postgres | false | false | false regards. -- Kyotaro Horiguchi NTT Open Source Software Center ^ permalink raw reply [nested|flat] 24+ messages in thread
end of thread, other threads:[~2023-04-14 07:28 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 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 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]> 2023-04-14 07:28 Re: psql: Add role's membership options to the \du+ command Kyotaro Horiguchi <[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