Konstantin Knizhnik schrieb am 05.07.2020 um 19:31:
I am surprised that you are saying you didn't feel big interest. My
reading of the thread is the opposite, that there was quite some
interest, but that there are technical challenges to overcome. So you
gave up on that work?
No, I have not
On 05.07.2020 08:48, Mitar wrote:
Hi!
On Fri, Jul 3, 2020 at 12:29 AM Konstantin Knizhnik
wrote:
Did you read this thread:
https://www.postgresql.org/message-id/flat/78aadf6b-86d4-21b9-9c2a-51f1efb8a499%40postgrespro.ru
I have proposed a patch for supporting time travel (AS OF) queries.
Hi!
On Fri, Jul 3, 2020 at 12:29 AM Konstantin Knizhnik
wrote:
> Did you read this thread:
> https://www.postgresql.org/message-id/flat/78aadf6b-86d4-21b9-9c2a-51f1efb8a499%40postgrespro.ru
> I have proposed a patch for supporting time travel (AS OF) queries.
> But I didn't fill a big interest
> But I didn't fill a big interest to it from community.
Just fyi, it is something that I use in my database design now (just hacked
together using ranges / exclusion constraints) and
would love for a well supported solution.
I've chimed in a couple times as this feature has popped up in
On 02.07.2020 21:55, Mitar wrote:
Hi!
(Sorry if this was already discussed, it looks pretty obvious, but I
could not find anything.)
I was thinking and reading about how to design the schema to keep
records of all changes which happen to the table, at row granularity,
when I realized that
Hi!
On Thu, Jul 2, 2020 at 7:51 PM Mark Dilger wrote:
> I expect these issues to be less than half what you would need to resolve,
> though much of the rest of it is less clear to me.
Thank you for this insightful input. I will think it over.
Mitar
--
http://mitar.tnode.com/
Hi!
On Thu, Jul 2, 2020 at 12:16 PM Thomas Munro wrote:
> This was a research topic in ancient times (somewhere I read that in
> some ancient version, VACUUM didn't originally remove tuples, it moved
> them to permanent write-only storage). Even after the open source
> project began, there was
> On Jul 2, 2020, at 5:58 PM, Mitar wrote:
>
>> Plus, wrap-around and freezing aren’t just nice-to-have features.
>
> Oh, I forgot about that. ctid is still just 32 bits? So then for such
> table with permanent MVCC this would have to be increased, to like 64
> bits or something. Then one
On Thu, Jul 2, 2020 at 2:56 PM Mitar wrote:
> Hi!
>
> (Sorry if this was already discussed, it looks pretty obvious, but I
> could not find anything.)
There have been a couple timetravel extensions done, each with their own
limitations. I don’t believe a perfect implementation could be done
Hi!
On Thu, Jul 2, 2020 at 12:12 PM David G. Johnston
wrote:
> Even for a single table how would you go about specifying this in a
> user-friendly way? Then consider joins.
One general answer: you use query rewriting. But what is user-friendly
depends on the use case. For me, the main
On Fri, Jul 3, 2020 at 6:56 AM Mitar wrote:
> I was thinking and reading about how to design the schema to keep
> records of all changes which happen to the table, at row granularity,
> when I realized that all this is already done for me by PostgreSQL
> MVCC. All rows (tuples) are already
On Thursday, July 2, 2020, Mitar wrote:
> make queries asking for
> results at the particular historical version of table state?
Even for a single table how would you go about specifying this in a
user-friendly way? Then consider joins.
> Is this something I would have to run a custom
Hi!
(Sorry if this was already discussed, it looks pretty obvious, but I
could not find anything.)
I was thinking and reading about how to design the schema to keep
records of all changes which happen to the table, at row granularity,
when I realized that all this is already done for me by
13 matches
Mail list logo
