2010/4/1 Bruce Momjian :
> I think one of the problems is that we do the truncate even if the table
> has not be touched by the query, which is poor behavior.
Thank you for the support.
Will be this problem registered?
PS
I see a workaround: switch off "on commit delete rows" on temp tables
and
2010/3/30 Tom Lane :
> I don't recall any operations at transaction start for such tables,
> but there may be some.
>
Both in СommitTransaction(void) and PrepareTransaction(void) we can
see PreCommit_on_commit_actions() call;
Here PreCommit_on_commit_actions()
case ONCOM
Artiom Makarov wrote:
> 2010/4/1 Bruce Momjian :
>
> > I think one of the problems is that we do the truncate even if the table
> > has not be touched by the query, which is poor behavior.
>
> Thank you for the support.
> Will be this problem registered?
I have it on my personal TODO and will tr
Tom Lane wrote:
> Artiom Makarov writes:
> > When temp tables with "on commit delete rows" exists, I can see a
> > strange delay at any ?begin? and ?commit?.
>
> A delay at commit is hardly surprising, because each such temp table
> requires filesystem operations at commit (basically an "ftruncat
Artiom Makarov writes:
> When temp tables with "on commit delete rows" exists, I can see a
> strange delay at any begin and commit.
A delay at commit is hardly surprising, because each such temp table
requires filesystem operations at commit (basically an "ftruncate").
I don't recall any oper
Hi!
We have a postgres database which accessed by clients app via PL/PGSQL
stored procedures ( 8.4.1 on x86_64 ubuntu 8.04 server).
For some reasons we use about 25 temp tables "on commit delete rows".
It widely used by our SP.
When temp tables with "on commit delete rows" exists, I can see a
str
