How to get number of rows of a PostgreSQL cursor?

user_8164797 0
Viewed 2258

I have a cursor created using the WITH HOLD option that allows the cursor to be used for subsequent transactions.

I would like to retrieve the number of rows that can be fetched by the cursor. Since the rows represented by a held cursor are copied into a temporary file or memory area, I am wondering if it is possible to retrieve that number in a straightforward way or if the only solution is to fetch all the records to count them.

In that case, a MOVE FORWARD ALL FROM <cursor> statement returns MOVE x. Where x is the number moved. The result is a command tag written to stdout, and I do not know how to retrieve that value in a pgsql function. GET DIAGNOSTICS <var> := ROW_COUNT only works for FETCH but not MOVE.

Here is a solution proposal, how do you think I can improve it ? (and is it possible to use MOVE instead of FETCH to retrieve the x value ?)

-- Function returning the number of rows available in the cursor
CREATE FUNCTION get_cursor_size(_cursor_name TEXT)
    RETURNS TEXT AS
$func$
DECLARE
    _n_rows int;
BEGIN
    -- Set cursor at the end of records
    EXECUTE format('FETCH FORWARD ALL FROM %I', _cursor_name);

    -- Retrieve number of rows
    GET DIAGNOSTICS _n_rows := ROW_COUNT;

    -- Set cursor at the beginning
    EXECUTE format('MOVE ABSOLUTE 0 FROM %I', _cursor_name);
    RETURN _n_rows;
END
$func$ LANGUAGE plpgsql;

Thank you very much for your help

plpgsql database-cursor postgresql
2 Answers

I don't believe there is a way to do that in PL/pgSQL.

As a workaround, you could define the cursor so that it includes a row number:

DECLARE c CURSOR WITH HOLD FOR
SELECT *, row_number() OVER ()
FROM (SELECT /* your original query */) AS s;

That is only marginally more expensive than the original query, and it allows you to position the cursor on the last row with MOVE and retrieve the row_number, which is the total number of rows.

user_64643080

Yes it is possible to use MOVE instead of FETCH to count the records in a cursor, with slightly improved performance. As it turns out we can indeed retrieve ROW_COUNT diagnostics from a MOVE cursor statement.

GOTCHA: Using EXECUTE does not update the GET DIAGNOSTICS for MOVE while it does for FETCH, and neither statements will update the FOUND variable.

This is not clearly stipulated in the PostgreSQL documentanion per se, but considering that MOVE does not produce any actual results it might make sense enough to be excused.

NOTE: The following examples do not reset the cursor position back to 0 as with the original example, allowing the function to be used with all cursor types especially NO SCROLL cursors which will reject backward movement by raising an error.

Using MOVE instead of FETCH

The holy grail of PostgreSQL cursor record count methods we've all been waiting for. Modify the function to take a refcursor as argument and instead execute the MOVE cursor statement directly which then makes ROW_COUNT available.

-- Function returning the number of rows available in the cursor
CREATE FUNCTION get_cursor_size(_cursor refcursor)
    RETURNS TEXT AS
$func$
DECLARE
    _n_rows int;
BEGIN
    -- Set cursor at the end of records
    MOVE FORWARD ALL FROM _cursor;
    -- Retrieve number of rows
    GET DIAGNOSTICS _n_rows := ROW_COUNT;

    RETURN _n_rows;
END
$func$ LANGUAGE plpgsql;

Alternative approaches using MOVE

Provided here for completion.

Another approach is to LOOP through the cursor until FOUND returns falsey, however this approach is notably slower than even the FETCH ALL method from the original example in the question.

-- Increment the cursor position and count the rows
CREATE FUNCTION get_cursor_size(_cursor refcursor)
    RETURNS TEXT AS
$func$
DECLARE
    _n_rows int := 0;
begin
    LOOP
        -- Move cursor position
        MOVE FORWARD 1 IN _cursor;
        -- While not found
        EXIT WHEN NOT FOUND;
        -- Increment counter
        _n_rows := _n_rows + 1;
    END LOOP;

    RETURN _n_rows;
END
$func$ LANGUAGE plpgsql;

Increasing the step size does improve performance but the result will be rounded up because FOUND will report success if the cursor has moved at all. To rectify this we can look up ROW_COUNT and increment by the actual amount moved instead.

-- Count the actual number of rows incremented
CREATE FUNCTION get_cursor_size(_cursor refcursor)
    RETURNS TEXT AS
$func$
DECLARE
    _n_rows int := 0;
    _move_count int;
begin
    LOOP
        -- Move cursor position
        MOVE FORWARD 100 IN _cursor;
        -- Until not found
        EXIT WHEN NOT FOUND;
        -- Increment counter
        GET DIAGNOSTICS _move_count := ROW_COUNT;
        _n_rows := _n_rows + _move_count;
    END LOOP;

    RETURN _n_rows;
END
$func$ LANGUAGE plpgsql;

With 50,000 records I had to increase the step size to 1000 before I noticed any improvement over FETCH ALL so unless there is something else worth doing simultaneously the incremental approach is less optimal.

Passing cursor functions

We will probably want to use this with cursor producing functions, like:

-- Get a reference cursor
CREATE FUNCTION get_refcursor()
    RETURNS refcursor AS
$func$
DECLARE
    return_cursor refcursor;
BEGIN
    OPEN return_cursor FOR SELECT 'One Record';
    RETURN return_cursor;
END
$func$ LANGUAGE plpgsql;

We can simplify this by using an OUT argument instead allowing us to omit both the declaration block and return statement, see the Create Function documentation.

-- Get a reference cursor
CREATE FUNCTION get_refcursor(OUT return_cursor refcursor)
    RETURNS refcursor AS
$func$
BEGIN
    OPEN return_cursor FOR SELECT 'One Record';
END
$func$ LANGUAGE plpgsql;

Using one of our get cursor functions we can now easily count the number of returned cursor records (only 1) by passing the function as argument.

SELECT get_cursor_size(get_refcursor());

nJoy!

user_15221170
Related