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 по дате отправления: