Re: Updatable view?

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 :)

In response to

Browse pgsql-hackers by date

  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