From: | Atri Sharma <atri(dot)jiit(at)gmail(dot)com> |
---|---|
To: | Tatsuo Ishii <ishii(at)postgresql(dot)org> |
Cc: | Pg Hackers <pgsql-hackers(at)postgresql(dot)org> |
Subject: | Re: Updatable view? |
Date: | 2015-07-31 06:45:19 |
Message-ID: | CAOeZVifQpjkg+RZkwetLH=Lu_uJNATvvip8fsz3f3m7BTgBAOA@mail.gmail.com |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
On 31 Jul 2015 11:59, "Tatsuo Ishii" <ishii(at)postgresql(dot)org> wrote:
>
> > On 31 Jul 2015 10:15, "Tatsuo Ishii" <ishii(at)postgresql(dot)org> wrote:
> >>
> >> > I think it would be nice to have... but not to the point of working
on
> >> > it myself.
> >> >
> >> > Might be worth an email to -general to see how many people have
> >> > immediate use for it.
> >>
> >> What I am thinking about is,
> >>
> >> 1) Implement certain class of updatable views allowed in SQL:1999
> >> (UNION ALL, natural joins)
> >>
> >> 2) Anything beyond #1 (I have no idea for now)
> >>
> >> Let me see how people are interested in...
> >>
> >
> > How does the standard define it? Do they also follow the same MVCC
> > semantics as normal tables?
>
> In my understanding there's no such concept like MVCC in the standard.
> Anyway in our implementation, we should keep the MVCC semantics of
> course.
>
Yes I meant our internal MVCC semantics. I will have to look at the way
MVCC handles views for exact logic though
> > I am concerned that we may end up losing read
> > performance for views if we implement this (unless I am missing
something)
>
> Why do updatable views lose read performance? I thought the only
> performance concern will be in the update/delete/insert operations.
I meant update, sorry. Pre coffee mails tend to be incorrect :)
From | Date | Subject | |
---|---|---|---|
Next Message | Peter Geoghegan | 2015-07-31 06:56:23 | Re: Using quicksort and a merge step to significantly improve on tuplesort's single run "external sort" |
Previous Message | Heikki Linnakangas | 2015-07-31 06:32:46 | Re: 64-bit XIDs again |