Re: MVCC and all that...

From: Justin <zzzzz(dot)graf(at)gmail(dot)com>
To: Ron Johnson <ronljohnsonjr(at)gmail(dot)com>
Cc: pgsql-general <pgsql-general(at)postgresql(dot)org>
Subject: Re: MVCC and all that...
Date: 2025-09-10 01:36:46
Message-ID: CALL-XeNMYtzMK_VbJe40kXn0N0AQ2cLoR0RsOmpvAqJDOzbpPQ@mail.gmail.com
Views: Whole Thread | Raw Message | Download mbox | Resend email
Thread:
Lists: pgsql-general

On Tue, Sep 9, 2025 at 9:12 PM Ron Johnson <ronljohnsonjr(at)gmail(dot)com> wrote:

> On Tue, Sep 9, 2025 at 8:41 PM Justin <zzzzz(dot)graf(at)gmail(dot)com> wrote:
>
>>
>> XID being 32 bit
>>
>
> Would converting them to 64 bits require changing the on-disk structure of
> database files?
>

Yes this is one of the reasons 64 bit xid has not be used yet. pg_upgrade
is not an option as the database must be reloaded.

>
>
>> anonymous functions in PG have several limitation not just input
>> arguments (not sure i see the need for that)
>>
>
> Aren't transience and "ad hockery" the whole point of anonymous
> procedures? Thus, I don't see the point of passing them parameters, either.
>

I agree. It would be nice to be able to return a result. I cheat using
RAISE NOTICE to get something back..

>
>
>> Temporary tables are a pain and cause issues for big databases
>>
>
> I'd like to see GLOBAL TEMPORARY tables. Each connection gets its own
> private copy of the table, so that applications don't need to carry around
> CREATE TEMPORARY TABLE code with them.
>
>
Temporary tables implementation is not optimal, In most cases I am able to
remove temp tables with better SQL, that does not require intermediate temp
tables to hold result sets that are used later in the logic. The SQL is
harder to write and understand .

Thanks
Justin

In response to

Browse pgsql-general by date

  From Date Subject
Next Message Ellen Allhatatlan 2025-09-10 07:41:14 Re: MVCC and all that...
Previous Message Ron Johnson 2025-09-10 01:11:33 Re: MVCC and all that...