Re: MERGE SQL statement for PG12

From: Pavan Deolasee <pavan(dot)deolasee(at)gmail(dot)com>
To: pgsql-hackers <pgsql-hackers(at)postgresql(dot)org>
Cc: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>, Alvaro Herrera <alvherre(at)2ndquadrant(dot)com>, Andres Freund <andres(at)anarazel(dot)de>
Subject: Re: MERGE SQL statement for PG12
Date: 2018-09-04 05:01:00
Message-ID: CABOikdPfySjjtw8aCJU=ittnmx9Co13n=XN9Da73yZX8=Bo24w@mail.gmail.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

I've rebased the patch against the current master. The patch hasn't changed
much since the last time.

I hope that the patch gets some review this CF so that we're left with
enough time to address those reviews and get the patch committed early in
the cycle. Copying Tom and Andres since they had expressed willingness to
review the patch in detail when the new development cycle opens. But fresh
reviews from Peter G, others is welcome too.

On Mon, Jun 25, 2018 at 11:13 PM Alvaro Herrera <alvherre(at)2ndquadrant(dot)com>
wrote:

>
> Hello. A very minor thing, please see commit 15a8f8caad14 and the
> discussion that led to it.
>
>
Alvaro, thanks for the reminder. I've fixed that in the rebased patch.
While working on it, I thought we should just consolidate these different
counters in an array. Something like this:

+typedef enum TupleCounterType
+{
+ TUPLE_COUNTER_PROCESSED = 0,
+ TUPLE_COUNTER_CONFLICTING,
+ TUPLE_COUNTER_IOS_HEAP_FETCHES,
+ TUPLE_COUNTER_MERGE_INSERTED,
+ TUPLE_COUNTER_MERGE_UPDATED,
+ TUPLE_COUNTER_MERGE_DELETED,
+ TUPLE_COUNTER_FILTERED_BY_JOIN_QUALS,
+ TUPLE_COUNTER_FILTERED_BY_OTHER_QUALS,
+ TUPLE_COUNTER_MAX_COUNT /* should be last */
+} TupleCounterType;
+
typedef struct Instrumentation
{
/* Parameters set at node creation: */
@@ -56,14 +69,9 @@ typedef struct Instrumentation
/* Accumulated statistics across all completed cycles: */
double startup; /* Total startup time (in seconds) */
double total; /* Total total time (in seconds) */
- double ntuples; /* Total tuples produced */
- /* Additional node-specific tuple counters */
- double node_ntuples1;
- double node_ntuples2;
- double node_ntuples3;
+ /* Tuple counters */
+ double ntuples[TUPLE_COUNTER_MAX_COUNT];
double nloops; /* # of run cycles for this node */
- double nfiltered1; /* # tuples removed by scanqual or joinqual */
- double nfiltered2; /* # tuples removed by "other" quals */
BufferUsage bufusage; /* Total buffer usage */
} Instrumentation;

And then have matching macros to get/set/manage those counters per type. Do
you see a value in doing so?

Thanks,
Pavan

--
Pavan Deolasee http://www.2ndQuadrant.com/
PostgreSQL Development, 24x7 Support, Training & Services

Attachment Content-Type Size
0001-MERGE-SQL-Command-following-SQL-2016_v2.patch application/octet-stream 391.5 KB

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Pavan Deolasee 2018-09-04 05:13:58 Re: Accidental removal of a file causing various problems
Previous Message Amit Kapila 2018-09-04 04:44:24 Re: pg_verify_checksums failure with hash indexes