Postgres Pro
Downloads
Home   >   mailing lists

Re: V8.4 TOAST table problem - Mailing list pgsql-general

From Bradley McCune
Subject Re: V8.4 TOAST table problem
Date
Msg-id CAPot_c-22W8c_+pxkcEOyi14ZGEbPo4Kvp=m0mQZ=fYSAgb0uw@mail.gmail.com
Whole thread Raw
In response to Re: V8.4 TOAST table problem  (David Welton <davidw@dedasys.com>)
Responses Re: V8.4 TOAST table problem
List pgsql-general
Tree view
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 by date:

Previous
From: Bradley McCune
Date:
Subject: Re: V8.4 TOAST table problem
Next
From: David Kerr
Date:
Subject: Re: Build RPM from Postgres Source