Re: V8.4 TOAST table problem

Поиск
Список
Период
Сортировка
От Bradley McCune
Тема Re: V8.4 TOAST table problem
Дата
Msg-id CAPot_c-22W8c_+pxkcEOyi14ZGEbPo4Kvp=m0mQZ=fYSAgb0uw@mail.gmail.com
обсуждение исходный текст
Ответ на Re: V8.4 TOAST table problem  (David Welton <davidw@dedasys.com>)
Ответы Re: V8.4 TOAST table problem  (David Welton <davidw@dedasys.com>)
Список pgsql-general
David,

I'm sorry, but I'm not sure that I follow how this is pertinent to this particular thread.  Are you proposing a way to replicate the scenario we experienced of our massively bloated TOAST table?  If so, I'm not entirely sure that's doable given that the source of the issue was never clear.  There still remains a number of reasons for why that table had so much "still in use" bloat.  At this moment, it's near impossible to tell given that it is no longer a problem.

Thanks for the offer, and I apologize if I'm just slightly ignorant about your intentions.


On Mon, Jul 15, 2013 at 4:33 AM, David Welton <davidw@dedasys.com> wrote:
Hi,

I think I could write a script to do something similar to what is
happening if anyone is interested.  I'd want some direction as to the
best way to handle this though: it'd be easier for me to script it as
Rails code because that's what the app is.  Perhaps from that we can
get the generated SQL so as to make it easier for others to deal with.
 The operation itself is basically:

* Extract a value from a row of a table that is stored as a bytea.

* Unmarshall it into a Ruby object.

* Add to that Ruby object.

* update the row and set the value by marshalling the Ruby object.

I suspect that the actual value isn't terribly relevant, and they
how's and why's of what it is like it is are best left for a different
discussion.

--
David N. Welton

http://www.dedasys.com/



--
Bradley D. J. McCune

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

Предыдущее
От: Bradley McCune
Дата:
Сообщение: Re: V8.4 TOAST table problem
Следующее
От: David Kerr
Дата:
Сообщение: Re: Build RPM from Postgres Source