Thanks to all for time and valuable help,
Pavel Rotek
2008/3/7, Bill Moran <[EMAIL PROTECTED]>:
>
> In response to "Pavel Rotek" <[EMAIL PROTECTED]>:
>
>
> > 2008/3/7, Tom Lane <[EMAIL PROTECTED]>:
>
>
> [snip]
>
>
> > > If you have to do it that way, you'll need very frequent vacuums on
> this
>
In response to "Pavel Rotek" <[EMAIL PROTECTED]>:
> 2008/3/7, Tom Lane <[EMAIL PROTECTED]>:
[snip]
> > If you have to do it that way, you'll need very frequent vacuums on this
> > table (not vacuum full, as noted already) to keep the toast space from
> > bloating too much. And make sure you've
"Pavel Rotek" <[EMAIL PROTECTED]> writes:
> 2008/3/7, Tom Lane <[EMAIL PROTECTED]>:
>> You mean that you build up the 5MB log entry by adding a few lines at a
>> time? That's going to consume horrid amounts of toast space, because
>> each time you add a few lines, an entire new toasted field value
2008/3/7, Matthew <[EMAIL PROTECTED]>:
>
> On Fri, 7 Mar 2008, Pavel Rotek wrote:
> > well, this will be the main problem... But... do uncomitted trasactions
> > affect toast space?
>
>
> I think the demonstrated answer to this is yes.
>
>
> > (begin tx, load previous log, do business action, appen
2008/3/7, Matthew <[EMAIL PROTECTED]>:
>
> > "Pavel Rotek" <[EMAIL PROTECTED]> writes:
> >> No i do not mean long running transactions... Update of log entry
> (update of
> >> row in dataaction) is performed in series of short transactions, but
> during
> >> short transaction there is a lot of chan
On Fri, 7 Mar 2008, Pavel Rotek wrote:
well, this will be the main problem... But... do uncomitted trasactions
affect toast space?
I think the demonstrated answer to this is yes.
(begin tx, load previous log, do business action, append new log, flush, do
business action, append new log, flush
2008/3/7, Tom Lane <[EMAIL PROTECTED]>:
>
> "Pavel Rotek" <[EMAIL PROTECTED]> writes:
> > No i do not mean long running transactions... Update of log entry
> (update of
> > row in dataaction) is performed in series of short transactions, but
> during
> > short transaction there is a lot of change l
"Pavel Rotek" <[EMAIL PROTECTED]> writes:
No i do not mean long running transactions... Update of log entry (update of
row in dataaction) is performed in series of short transactions, but during
short transaction there is a lot of change log value, flush, change log
value ,flush . change log
"Pavel Rotek" <[EMAIL PROTECTED]> writes:
> No i do not mean long running transactions... Update of log entry (update of
> row in dataaction) is performed in series of short transactions, but during
> short transaction there is a lot of change log value, flush, change log
> value ,flush . chang
Pavel Rotek escribió:
> 2008/3/7, Bill Moran <[EMAIL PROTECTED]>:
> > Don't do vacuum full on this table. Do frequent vacuums. The table will
> > bloat some, but not 10x the required size, once you find a reasonable
> > frequency for vacuums. You might find it practical to manually vacuum
> > t
2008/3/7, Bill Moran <[EMAIL PROTECTED]>:
>
> In response to "Pavel Rotek" <[EMAIL PROTECTED]>:
>
> >
> > There are inserts and few updates (but what do you mean with update??
>
>
> He means adding or changing data in the table.
I understand, but i don't have deep understanding of mechanism, that
In response to "Pavel Rotek" <[EMAIL PROTECTED]>:
>
> There are inserts and few updates (but what do you mean with update??
He means adding or changing data in the table.
> committed update??, because there are many updates of the log attribute in
> trasaction, we do periodical flush during tran
we just restored it to free 70G :-(
There are inserts and few updates (but what do you mean with update??
committed update??, because there are many updates of the log attribute in
trasaction, we do periodical flush during transaction), sum takes
approximately 1,2G, and i mean vacuum full (but the
Pavel Rotek wrote:
Hello,
i have problem with following table...
create table dataaction (
id INT4 not null,
log text,
primary key (id)
);
It is the table for storing results of long running jobs. The log attribute
takes approximately 5MB for one row (there is about 300 rows). My prob
Hello,
i have problem with following table...
create table dataaction (
id INT4 not null,
log text,
primary key (id)
);
It is the table for storing results of long running jobs. The log attribute
takes approximately 5MB for one row (there is about 300 rows). My problem
is, that table da
15 matches
Mail list logo
