Thread: pgsql: Widen query numbers-of-tuples-processed counters to uint64.

pgsql: Widen query numbers-of-tuples-processed counters to uint64.

From
Tom Lane
Date:
Widen query numbers-of-tuples-processed counters to uint64.

This patch widens SPI_processed, EState's es_processed field, PortalData's
portalPos field, FuncCallContext's call_cntr and max_calls fields,
ExecutorRun's count argument, PortalRunFetch's result, and the max number
of rows in a SPITupleTable to uint64, and deals with (I hope) all the
ensuing fallout.  Some of these values were declared uint32 before, and
others "long".

I also removed PortalData's posOverflow field, since that logic seems
pretty useless given that portalPos is now always 64 bits.

The user-visible results are that command tags for SELECT etc will
correctly report tuple counts larger than 4G, as will plpgsql's GET
GET DIAGNOSTICS ... ROW_COUNT command.  Queries processing more tuples
than that are still not exactly the norm, but they're becoming more
common.

Most values associated with FETCH/MOVE distances, such as PortalRun's count
argument and the count argument of most SPI functions that have one, remain
declared as "long".  It's not clear whether it would be worth promoting
those to int64; but it would definitely be a large dollop of additional
API churn on top of this, and it would only help 32-bit platforms which
seem relatively less likely to see any benefit.

Andreas Scherbaum, reviewed by Christian Ullrich, additional hacking by me

Branch
------
master

Details
-------
http://git.postgresql.org/pg/commitdiff/23a27b039d94ba359286694831eafe03cd970eef

Modified Files
--------------
contrib/auto_explain/auto_explain.c             |   4 +-
contrib/pg_stat_statements/pg_stat_statements.c |  12 +--
contrib/spi/refint.c                            |   2 +-
contrib/tablefunc/tablefunc.c                   |  28 +++---
contrib/xml2/xpath.c                            |   6 +-
doc/src/sgml/spi.sgml                           |  17 ++--
src/backend/commands/createas.c                 |   2 +-
src/backend/commands/portalcmds.c               |  14 +--
src/backend/executor/execMain.c                 |  12 +--
src/backend/executor/functions.c                |   4 +-
src/backend/executor/spi.c                      |  24 ++---
src/backend/tcop/pquery.c                       | 114 +++++++++++++-----------
src/backend/utils/adt/numutils.c                |  22 +++++
src/backend/utils/adt/tsquery_rewrite.c         |   3 +-
src/backend/utils/adt/tsvector_op.c             |   3 +-
src/backend/utils/adt/xml.c                     |  10 +--
src/include/executor/executor.h                 |   6 +-
src/include/executor/spi.h                      |   6 +-
src/include/executor/spi_priv.h                 |   2 +-
src/include/funcapi.h                           |   4 +-
src/include/nodes/execnodes.h                   |   2 +-
src/include/postgres.h                          |  27 ++++++
src/include/tcop/pquery.h                       |   2 +-
src/include/utils/builtins.h                    |   1 +
src/include/utils/portal.h                      |  11 ++-
src/pl/plperl/plperl.c                          |  25 ++++--
src/pl/plpgsql/src/pl_exec.c                    |  20 ++---
src/pl/plpgsql/src/plpgsql.h                    |   2 +-
src/pl/plpython/plpy_cursorobject.c             |  18 +++-
src/pl/plpython/plpy_spi.c                      |  28 ++++--
src/pl/tcl/pltcl.c                              |  19 ++--
src/test/regress/regress.c                      |   4 +-
32 files changed, 273 insertions(+), 181 deletions(-)


Re: pgsql: Widen query numbers-of-tuples-processed counters to uint64.

From
Andres Freund
Date:

On March 12, 2016 1:05:46 PM PST, Tom Lane <tgl@sss.pgh.pa.us> wrote:

>Most values associated with FETCH/MOVE distances, such as PortalRun's
>count
>argument and the count argument of most SPI functions that have one,
>remain
>declared as "long".  It's not clear whether it would be worth promoting
>those to int64; but it would definitely be a large dollop of additional
>API churn on top of this, and it would only help 32-bit platforms which
>seem relatively less likely to see any benefit.

There's also windows, where long is 32 bit, even on 64bit platforms...

Andres
--
Sent from my Android device with K-9 Mail. Please excuse my brevity.


Re: pgsql: Widen query numbers-of-tuples-processed counters to uint64.

From
Tom Lane
Date:
Andres Freund <andres@anarazel.de> writes:
> On March 12, 2016 1:05:46 PM PST, Tom Lane <tgl@sss.pgh.pa.us> wrote:
>> Most values associated with FETCH/MOVE distances, such as PortalRun's
>> count argument and the count argument of most SPI functions that have
>> one, remain declared as "long".  It's not clear whether it would be
>> worth promoting those to int64; but it would definitely be a large
>> dollop of additional API churn on top of this, and it would only help
>> 32-bit platforms which seem relatively less likely to see any benefit.

> There's also windows, where long is 32 bit, even on 64bit platforms...

I'm not personally excited about doing a lot of work, and possibly
breaking a lot (more) extensions, to provide a mostly-academic benefit
to Windows64 and little else.  But, if someone else wants to tackle it
I won't stand in the way.

            regards, tom lane