Search Postgresql Archives

Re: explain plan visibility

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



高健 wrote:
> Please let me dig it a little more:
> 
> I think that  when a session is accessing a postgersql table. It will be influenced by  the
> followings:
> 
> 
> 
> Really old data (needed to be vacuumed, eg: old image at one day ago).
> 
> Recent data (committed and uncommitted), because they are all in the data block.
> 
> 
> 
> Isn’t it strange that I have to access my data among somebody’s un-decided data?
> 
> How if there is a busy system having a table accessed by so many sessions at same time?
> 
> They will all be slowed down because of uncommitted but flushed out data, I think.
> 
> 
> 
> I hope in future the architecture of PostgreSQL can put the committed data & uncommitted data apart,
> 
> Or even put them in separate physical disks.That will Help to improve performance I think.

I don't think that this design choice will ever be changed.

You'll always be influenced by other people's data, no
matter how you handle MVCC.

Let's imagine a design where yet uncommitted data are
stored somewhere else.  How do you handle the following
problems:

1) The space for uncommitted data runs out.  That will keep you
   from doing any transaction exceeding the size of this storage
   space.  Note that Oracle suffers from that problem (though
   they do the opposite of what you propose:  they store uncommitted
   data in the table and move old data to the "undo space").

2) Every COMMIT will require that everything is moved from the
   "uncommited space" to the regular table.  So you'd double the
   I/O cost for the normal case (I guess that's the reason why
   Oracle does it the other way round).

And you wouldn't even get rid of the most unpleasant side effect
of the way that PostgreSQL manages MVCC, the need to VACUUM away
old tuples.

As for Oracle's approach to MVCC, which I think is better than yours,
it has its pros and cons, but I don't think it is demonstrably better
than PostgreSQL's.  No matter how you implement MVCC, you'll have to
pay the price for the benefits somehow.

Yours,
Laurenz Albe

-- 
Sent via pgsql-general mailing list (pgsql-general@xxxxxxxxxxxxxx)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-general



[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
[Index of Archives]     [Postgresql Jobs]     [Postgresql Admin]     [Postgresql Performance]     [Linux Clusters]     [PHP Home]     [PHP on Windows]     [Kernel Newbies]     [PHP Classes]     [PHP Books]     [PHP Databases]     [Postgresql & PHP]     [Yosemite]
  Powered by Linux