You signed in with another tab or window.Reload to refresh your session.You signed out in another tab or window.Reload to refresh your session.You switched accounts on another tab or window.Reload to refresh your session.Dismiss alert
Widen query numbers-of-tuples-processed counters to uint64.
This patch widens SPI_processed, EState's es_processed field, PortalData'sportalPos field, FuncCallContext's call_cntr and max_calls fields,ExecutorRun's count argument, PortalRunFetch's result, and the max numberof rows in a SPITupleTable to uint64, and deals with (I hope) all theensuing fallout. Some of these values were declared uint32 before, andothers "long".I also removed PortalData's posOverflow field, since that logic seemspretty useless given that portalPos is now always 64 bits.The user-visible results are that command tags for SELECT etc willcorrectly report tuple counts larger than 4G, as will plpgsql's GETGET DIAGNOSTICS ... ROW_COUNT command. Queries processing more tuplesthan that are still not exactly the norm, but they're becoming morecommon.Most values associated with FETCH/MOVE distances, such as PortalRun's countargument and the count argument of most SPI functions that have one, remaindeclared as "long". It's not clear whether it would be worth promotingthose to int64; but it would definitely be a large dollop of additionalAPI churn on top of this, and it would only help 32-bit platforms whichseem relatively less likely to see any benefit.Andreas Scherbaum, reviewed by Christian Ullrich, additional hacking by me