On Mon, 2008-09-22 at 07:53 -0400, Tom Lane wrote:
Simon Riggs [EMAIL PROTECTED] writes:
I think the issue is identifying the problem. Reading the title of the
post, I think Tom says no to *deleting* the toast table. He also says
no to cleaning the table as part of DROP COLUMN. That still
On Sun, 2008-09-21 at 12:05 -0400, Tom Lane wrote:
Zoltan Boszormenyi [EMAIL PROTECTED] writes:
we came across a database where a table had a toasted table,
keeping huge amounts of disk space allocated. However,
the table's current definition didn't explain why there was
a toasted table.
Hannu Krosing [EMAIL PROTECTED] writes:
On Sun, 2008-09-21 at 12:05 -0400, Tom Lane wrote:
The DROP COLUMN form does not physically remove the column, but
simply makes it invisible to SQL operations. Subsequent insert and
update operations in the table will store a null value for the
column.
On Sun, 2008-09-21 at 12:05 -0400, Tom Lane wrote:
... and it goes on to point out how to force immediate space reclamation
if you need that. These statements apply independently of whether any
particular value is toasted or not.
The reason for this choice is that reclaiming the space
On Sep 22, 2008, at 9:46 AM, Simon Riggs wrote:
On Sun, 2008-09-21 at 12:05 -0400, Tom Lane wrote:
... and it goes on to point out how to force immediate space
reclamation
if you need that. These statements apply independently of whether
any
particular value is toasted or not.
The
On Mon, 2008-09-22 at 10:59 +0200, Hans-Jürgen Schönig wrote:
On Sep 22, 2008, at 9:46 AM, Simon Riggs wrote:
I thought Hans meant cleanup, not drop?
we definitely have to do something about this problem.
I think the issue is identifying the problem. Reading the title of the
post, I think
Simon Riggs [EMAIL PROTECTED] writes:
I think the issue is identifying the problem. Reading the title of the
post, I think Tom says no to *deleting* the toast table. He also says
no to cleaning the table as part of DROP COLUMN. That still leaves you
an opening for an out-of-line
On Mon, 2008-09-22 at 07:53 -0400, Tom Lane wrote:
Simon Riggs [EMAIL PROTECTED] writes:
I think the issue is identifying the problem. Reading the title of the
post, I think Tom says no to *deleting* the toast table. He also says
no to cleaning the table as part of DROP COLUMN. That still
Tom Lane [EMAIL PROTECTED] writes:
Simon Riggs [EMAIL PROTECTED] writes:
I think the issue is identifying the problem. Reading the title of the
post, I think Tom says no to *deleting* the toast table. He also says
no to cleaning the table as part of DROP COLUMN. That still leaves you
an
Gregory Stark [EMAIL PROTECTED] writes:
Hmm I wonder if this doesn't have the same problems you're describing with
the toaster. If someone has a cursor WITH HOLD against the table they don't
get a session level lock against the tables which fed the cursor do
they?
Hmm, interesting point.
Hi,
we came across a database where a table had a toasted table,
keeping huge amounts of disk space allocated. However,
the table's current definition didn't explain why there was
a toasted table. Then upon some experiments, it struck me.
There _was_ a toasted field but as the schema was
Zoltan Boszormenyi [EMAIL PROTECTED] writes:
we came across a database where a table had a toasted table,
keeping huge amounts of disk space allocated. However,
the table's current definition didn't explain why there was
a toasted table. Then upon some experiments, it struck me.
There _was_ a
*snip*
Judging from that, the toasted table
cleanup may be part of ALTER TABLE DROP COLUMN.
That would only help if you were dropping the last potentially-
toastable
column of a table. And implementing it would require introducing
weird
corner cases into the tuple toaster, because it
=?ISO-8859-1?Q?Hans-J=FCrgen_Sch=F6nig?= [EMAIL PROTECTED] writes:
... And implementing it would require introducing weird
corner cases into the tuple toaster, because it might now come across
TOAST pointers that point to a no-longer-existent table, and have to
consider that to be a no-op
14 matches
Mail list logo
