Re: shared memory stats: high level design decisions: consistency, dropping

Поиск
Список
Период
Сортировка
От Tom Lane
Тема Re: shared memory stats: high level design decisions: consistency, dropping
Дата
Msg-id 382908.1616343275@sss.pgh.pa.us
обсуждение исходный текст
Ответ на shared memory stats: high level design decisions: consistency, dropping  (Andres Freund <andres@anarazel.de>)
Ответы Re: shared memory stats: high level design decisions: consistency, dropping  (Stephen Frost <sfrost@snowman.net>)
Re: shared memory stats: high level design decisions: consistency, dropping  (Andres Freund <andres@anarazel.de>)
Re: shared memory stats: high level design decisions: consistency, dropping  (Robert Haas <robertmhaas@gmail.com>)
Список pgsql-hackers
Andres Freund <andres@anarazel.de> writes:
> 1) What kind of consistency do we want from the pg_stats_* views?

That's a hard choice to make.  But let me set the record straight:
when we did the initial implementation, the stats snapshotting behavior
was considered a FEATURE, not an "efficiency hack required by the old
storage model".

If I understand what you are proposing, all stats views would become
completely volatile, without even within-query consistency.  That really
is not gonna work.  As an example, you could get not-even-self-consistent
results from a join to a stats view if the planner decides to implement
it as a nestloop with the view on the inside.

I also believe that the snapshotting behavior has advantages in terms
of being able to perform multiple successive queries and get consistent
results from them.  Only the most trivial sorts of analysis don't need
that.

In short, what you are proposing sounds absolutely disastrous for
usability of the stats views, and I for one will not sign off on it
being acceptable.

I do think we could relax the consistency guarantees a little bit,
perhaps along the lines of only caching view rows that have already
been read, rather than grabbing everything up front.  But we can't
just toss the snapshot concept out the window.  It'd be like deciding
that nobody needs MVCC, or even any sort of repeatable read.

            regards, tom lane



В списке pgsql-hackers по дате отправления:

Предыдущее
От: Joe Conway
Дата:
Сообщение: Re: "has_column_privilege()" issue with attnums and non-existent columns
Следующее
От: Tom Lane
Дата:
Сообщение: Re: "has_column_privilege()" issue with attnums and non-existent columns