On 10.01.2018 16:02, legrand legrand wrote:
>> But performing this query on each access to the table seems to be bad
>> idea: in case of nested loop join it can cause significant degrade of
>> performance.
> this could be a pre-plan / pre-exec check, no more.
AS-OF timestamp can be taken from outer table, so it is necessary to
repeat this check at each nested loop join iteration.
>
>> But I am not sure that this check is actually needed.
>> If table is changed in some incompatible way, then we will get error in
>> any case.
> It seems that with path v3, a query with asof_timestamp
> set before a truncate or alter table doesn't throw any error,
> just gives an empty result (even if there was data).
Sorry, truncate is not compatible with AS OF. It is performed at file
level and deletes old old version.
So if you want to use time travel, you should not use truncate.
>
>> If table change is not critical for this query (for example some column
>> was added or removed which is not used in this query),
>> then should we really throw error in this case?
> no error is needed if result is correct.
Does it mean that no explicit check is needed that table metadata was
not checked after specified timeslice?
Attached please find new version of the AS OF patch which throws error
if specified AS OF timestamp is older that time travel horizon and
"check_asof_timestamp" parameter is set to true (by default it is
switched off).
--
Konstantin Knizhnik
Postgres Professional: http://www.postgrespro.com
The Russian Postgres Company