I think the table is dropped by end of function
> On Jan 28, 2018, at 2:45 PM, David G. Johnston
> wrote:
>
>> On Sunday, January 28, 2018, Rob Sargent wrote:
>> The commit in question is the function btw.
>
> That doesn't make sense - functions can't commit.
>
> David J.
On Sunday, January 28, 2018, Rob Sargent wrote:
>
> The commit in question is the function btw.
>
That doesn't make sense - functions can't commit.
David J.
“On commit drop” is generally good practice for several reasons: if your
function is called in a loop, or the create statement is in a loop or you want
to call your function more than once in a given session (with out explicitly
dropping your temp table).
The commit in question is the function
On 01/28/2018 08:46 AM, Ryan Murphy wrote:
I believe the main, and maybe only, concern is the bloating of the system
catalog tables since you are constantly adding and removing records. Yes, they
will be vacuumed but vacuuming and bloat on catalog tables slows every single
query down to s
>
> I believe the main, and maybe only, concern is the bloating of the system
> catalog tables since you are constantly adding and removing records. Yes,
> they will be vacuumed but vacuuming and bloat on catalog tables slows every
> single query down to some, degree since every query has to looku
On Sunday, January 28, 2018, Ryan Murphy wrote:
> Hello,
>
> I heard at a PostgreSQL talk that you should not liberally create temp
> tables in the course of frequently-used functions etc, because (roughly)
> you're using up some of the same resources that you for your regular tables.
>
> Is this
Hello,
I heard at a PostgreSQL talk that you should not liberally create temp
tables in the course of frequently-used functions etc, because (roughly)
you're using up some of the same resources that you for your regular tables.
Is this true? Is there an important reason not to have e.g. a plpgsq
