Re: Improve pg_stat_statements scalability

Hi,

A quick update here.

> As it stands now, FLUSH_LOCK_CONFLICT and FLUSH_PARTIAL require the same
> action (keep pending, retry later), but at least it is explicit why we
> are retrying. This also forces extension authors to choose the correct
> return value rather than blindly returning true/false.
>
> Does this match what you had in mind?

To keep this thread better organized, I moved the mid-transaction flush
discussion to its own thread [1].

Also, a week ago e65c331b8fbf8c9 was committed which added
pgstat_prep_pending_from_entry_ref(). This allows extensions
to have fine grained control over entry creation by allowing
separate steps for lookup, creation and pending setup of
an entry. This is vital for for the work being done for pg_stat_statements.

[2] is still needed but I can proceed with the work even with the
pg_stat_statements
work for now since it's a transparent change to the extension; giving
an extension
the ability to have a dedicated dshash/dsa. But, nevertheless, I do believe this
will be needed for proper management/accounting for the stats created
by a custom kind.

[1] https://www.postgresql.org/message-id/CAA5RZ0u84eMFeFWMaEo0D84ed3jF_RY0%3DRWD8tDwQWsNsU1qvA%40mail.gmail.com
[2] https://www.postgresql.org/message-id/CAA5RZ0supQBxSkh=CWB39=j+cL3hHcLPki3tcBk0B1r4fesg_g@mail.gmail.com

--
Sami Imseih
Amazon Web Services (AWS)