Re: RFC: Restructuring pg_aggregate
От | Hiroshi Inoue |
---|---|
Тема | Re: RFC: Restructuring pg_aggregate |
Дата | |
Msg-id | 3CB50AA1.5EAB691D@tpf.co.jp обсуждение исходный текст |
Ответ на | Re: RFC: Restructuring pg_aggregate (Bruce Momjian <pgman@candle.pha.pa.us>) |
Ответы |
Re: RFC: Restructuring pg_aggregate
Re: RFC: Restructuring pg_aggregate |
Список | pgsql-hackers |
Bruce Momjian wrote: > > Hiroshi Inoue wrote: > > > > Why ? As you already mentioned, there were not that many places > > > > to be changed. > > > > > > > > Well what's changed since then ? > > > > > > Here is an old email from me that outlines the idea of having a > > > physical/logical attribute numbering system, and the advantages. > > > > I already tried physical/logical attribute implementation > > pretty long ago. Where are new ideas to solve the problems > > that the approach has ? > > Good question. I am suggesting more than just the drop column fix. It > could be used for smaller data files to reduce padding, fix for > inheritance problems with ADD COLUMN, and performance of moving > varlena's to the end of the row. > > Also, my idea was to have the physical/logical mapping happen closer to > the client, so the backend mostly only deals with physical. If the client has to bear the some part, isn't the invisible column approach much simpler ? I've put a pretty much time into DROP COLUMN feature but I am really disappointed to see the comments in this thread. What DROP COLUMN has brought me seems only a waste of time. Possibly I must have introduced either implementation forcibly. regards, Hiroshi Inoue
В списке pgsql-hackers по дате отправления: