Re: MVCC and all that...

Поиск
Список
Период
Сортировка
От Ellen Allhatatlan
Тема Re: MVCC and all that...
Дата
Msg-id CAMLfE0NMosrY6__P-PVbV3yCLh1Gp1jWpqAm3oJ=PS3mh97oNg@mail.gmail.com
обсуждение исходный текст
Ответ на Re: MVCC and all that...  (Adrian Klaver <adrian.klaver@aklaver.com>)
Ответы Re: MVCC and all that...
Список pgsql-general
> Though I would like to know what happened in mid 2010?:
> https://github.com/FirebirdSQL/firebird/graphs/contributors

Yes, indeed, WTF? I'm not a member of the FB Illuminati - so I can't say!

> > OK again. I'm just wondering if the single file per database isn't a
> > fundamental architectural flaw in itself? AIUI, you could have
> > mulitple files (back in 32-bit land) "chained" - but (again AIUI) the
> > same table could be spread over x files - all "intermingled"... weird.

> What are you referring to above?

I'm sorry -  the single file flaw I was referring to occurs in FB and
has nothing to do with PG.

FB dbs are single files - or were - 32 bit - up to 2GB and then there
was another file. I don't know what happens for 64 bit - (note to self
- find out)!

So, you have table X - it has 2M rows (say, 0.5 GB) in the first file
(along with all the other tables). The 2GB limit is hit, more data is
added. 0.7 GB is added to table X - these records go into a new
database file - the table is split in two - you have 2 "extents" of
2GB with X split 0.5 - in extent1, 0.7 in extent2. All mixed up with
other tables as well!

That was the architectural flaw to which I was referring. Nothing to
do with PG, backups or anything like that - again, apologies for any
confusion - my phraseology wasn't the best! And I should have put what
I wrote elsewhere anyway!


-- 

El!



В списке pgsql-general по дате отправления: