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
