Re: [HACKERS] LONG
От | wieck@debis.com (Jan Wieck) |
---|---|
Тема | Re: [HACKERS] LONG |
Дата | |
Msg-id | m11wv7m-0003kGC@orion.SAPserv.Hamburg.dsh.de обсуждение исходный текст |
Ответ на | Re: [HACKERS] LONG (Bruce Momjian <pgman@candle.pha.pa.us>) |
Ответы |
Re: [HACKERS] LONG
|
Список | pgsql-hackers |
Bruce Momjian wrote: > > While this is great and all, what will happen when long tuples finally get > > done? Will you remove this, or keep it, or just make LONG and TEXT > > equivalent? I fear that elaborate structures will be put in place here > > that might perhaps only be of use for one release cycle. > > I think the idea is that Jan's idea is better than chaining tuples. Just as Tom already pointed out, it cannot completely replace tuple chaining because of the atomicy assumption of single fsync(2) operation in current code. Due to this, we cannot get around the cases LONG will leave open by simply raising BLKSIZE, we instead need to tackle that anyways. But I believe LONG would still be something worth the efford. It will lower the pressure on chained tuples, giving us more time to build a really good solution, and I think LONG can survive tuple chaining and live in coexistance with it. As said in my last mail, I still believe that not touching LONG values at UPDATE can avoid storing the same huge value again. And that's a benefit, tuple chaining will never give us. Remember: If your only tool is a hammer, anything MUST look like a nail. So why not provide a richer set of tools? Jan -- #======================================================================# # It's easier to get forgiveness for being wrong than for being right. # # Let's break this rule - forgive me. # #========================================= wieck@debis.com (Jan Wieck) #
В списке pgsql-hackers по дате отправления: