public inbox for [email protected]
help / color / mirror / Atom feedFrom: Ron Johnson <[email protected]>
To: pgsql-general <[email protected]>
Subject: Re: MVCC and all that...
Date: Tue, 9 Sep 2025 21:11:33 -0400
Message-ID: <CANzqJaBvw-CAFyE+v2c91PBQazO0Y7sTP8gxqQh6XKDVv=8y+Q@mail.gmail.com> (raw)
In-Reply-To: <CALL-XeM=0oH=2ECawmyCOv2umKF1nyqr97CuQXiPfO39uhCucQ@mail.gmail.com>
References: <CAMLfE0MAVH5YORs0OKmD=fFWH9EtuNsnhViti=+hkp3Kbz-Gfw@mail.gmail.com>
<CAHyXU0yrwoEYia0mZhpjQLMdd-WXpWFM+Au1jXQpk3MtBvdogw@mail.gmail.com>
<CAMLfE0MWqALMJ99dpFniZ1xknCgHj4ETPWro+Ry9awPUG1OKMw@mail.gmail.com>
<CAHyXU0y2gZfH_ZomazQB7H0KkuyV3QofvuvZcSYXEhpotG=hMA@mail.gmail.com>
<CALL-XeM=0oH=2ECawmyCOv2umKF1nyqr97CuQXiPfO39uhCucQ@mail.gmail.com>
On Tue, Sep 9, 2025 at 8:41 PM Justin <[email protected]> wrote:
> I read through the article its click bait/flame war just waiting to happen.
>
> Article is a list of cherry picked PG drawbacks that can be mitigated or
> worked around.
>
> On the bulk updating. I'm shaking my finger at any one that locks up 25%
> of a table with an update or delete. That is asking for problems in a
> production database with a high TPS rate.
>
> The author brings up threaded vs multi-process. That's an old old old old
> old conversation that has been shown there is no clear better way.
>
> Number of open connections. so firebird can do 1000 open sessions with a
> smaller memory footprint, still can not have 1000 simultaneous running
> sessions unless we have 1000 CPU's. Where is the win here?? We should be
> managing resources better on the application side, not opening thousands of
> connections that sit idle doing nothing.
>
> On autonomous transactions we have procedures now that allow transactions
> inside of transactions that can be committed and rollbacked. that has been
> around for several years now.
>
> Backup argument is cherry picking and not discussing pgBackrest and other
> solutions or the use of tablespaces to isolate databases in a cluster at
> the disk layer or disk snapshots.
>
> "PostgreSQL has a relatively simple, but fast query planning algorithm"
> Compared to what.... What feature is PG missing these days... the only
> thing I know it can't do is change the plan in the middle of the
> execution stage. Which is not a query planner thing but the execution
> layer saying to itself I am taking too long maybe go back to the planning
> stage... Query Hints that have been discussed endlessly. Adding hints
> adds its own problems and has become a big mess for databases that support
> it.
>
> Multiple transactions per connection. I am asking WHY is that a feature.
> when one can have multiple sessions, what is the difference? running
> multiple transactions in single or multiple sessions means moving part of
> transaction logic into the application space. What do we gain here.....
>
> No application packaging. This Oracle thing that firebird has duplicated
> at some level. we can simulate this with namespace/schemas.
>
>
> I can keep going on here.
>
> There are litigmate points here
> Compression,
> not being able to return partials result sets from functions
> XID being 32 bit
>
Would converting them to 64 bits require changing the on-disk structure of
database files?
> 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.
(When I *do* need something similar, I build the DO block as a bash string
variable with environment variables as "parameters", and then execute it
via psql -c "$sql" More like a template, TBH. It's great for purging old
data from tables, since I can bypass records who's DELETE statements fail
due to a FK constraint.
> 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.
--
Death to <Redacted>, and butter sauce.
Don't boil me, I'm still alive.
<Redacted> lobster!
view thread (21+ messages) latest in thread
reply
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Reply to all the recipients using the --to and --cc options:
reply via email
To: [email protected]
Cc: [email protected]
Subject: Re: MVCC and all that...
In-Reply-To: <CANzqJaBvw-CAFyE+v2c91PBQazO0Y7sTP8gxqQh6XKDVv=8y+Q@mail.gmail.com>
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
This inbox is served by agora; see mirroring instructions
for how to clone and mirror all data and code used for this inbox