Re: AS OF queries

From: Peter Eisentraut <peter(dot)eisentraut(at)2ndquadrant(dot)com>
To: Konstantin Knizhnik <k(dot)knizhnik(at)postgrespro(dot)ru>, Jeff Janes <jeff(dot)janes(at)gmail(dot)com>
Cc: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>, Laurenz Albe <laurenz(dot)albe(at)cybertec(dot)at>, PostgreSQL Hackers <pgsql-hackers(at)postgresql(dot)org>
Subject: Re: AS OF queries
Date: 2017-12-28 17:28:52
Message-ID: 74747f47-188c-961a-50c1-daee08cf603f@2ndquadrant.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

On 12/28/17 11:36, Konstantin Knizhnik wrote:
> Attached please find new version of AS OF patch which allows to specify
> time travel period.
> Older versions outside this period may be reclaimed by autovacuum.
> This behavior is controlled by "time_travel_period" parameter.

So where are we on using quasi SQL-standard syntax for a nonstandard
interpretation? I think we could very well have a variety of standard
and nonstandard AS OF variants, including by commit timestamp, xid,
explicit range columns, etc. But I'd like to see a discussion on that,
perhaps in a documentation update, which this patch is missing.

I have questions about corner cases. What happens when multiple tables
are queried with different AS OF clauses? Can there be apparent RI
violations? What happens when the time_travel_period is changed during
a session? How can we check how much old data is available, and how can
we check how much space it uses? What happens if no old data for the
selected AS OF is available? How does this interact with catalog
changes, such as changes to row-level security settings? (Do we apply
the current or the past settings?)

This patch should probably include a bunch of tests to cover these and
other scenarios.

(Maybe "period" isn't the best name, because it implies a start and an
end. How about something with "age"?)

--
Peter Eisentraut http://www.2ndQuadrant.com/
PostgreSQL Development, 24x7 Support, Remote DBA, Training & Services

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Tels 2017-12-28 18:18:19 Re: plpgsql function startup-time improvements
Previous Message Magnus Hagander 2017-12-28 17:21:46 Re: Basebackups reported as idle