Re: MVCC and all that...
| От | Justin |
|---|---|
| Тема | Re: MVCC and all that... |
| Дата | |
| Msg-id | CALL-XeM=0oH=2ECawmyCOv2umKF1nyqr97CuQXiPfO39uhCucQ@mail.gmail.com обсуждение исходный текст |
| Ответ на | Re: MVCC and all that... (Merlin Moncure <mmoncure@gmail.com>) |
| Ответы |
Re: MVCC and all that...
Re: MVCC and all that... Re: MVCC and all that... Re: MVCC and all that... |
| Список | pgsql-general |
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.
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.
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.....
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
anonymous functions in PG have several limitation not just input arguments (not sure i see the need for that)
Temporary tables are a pain and cause issues for big databases
The article is unfair in many places..
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
anonymous functions in PG have several limitation not just input arguments (not sure i see the need for that)
Temporary tables are a pain and cause issues for big databases
The article is unfair in many places..
On Tue, Sep 9, 2025 at 6:55 PM Merlin Moncure <mmoncure@gmail.com> wrote:
On Tue, Sep 9, 2025 at 11:57 AM Ellen Allhatatlan <ellenallhatatlan@gmail.com> wrote:> Note: your link is wrong, corrected here:
Extra hyphen - sorry about and thanks for pointing it out!
> What the article is driving at is that postgres does not use rollback logs to handle updated records in the MVCC implementation. There are absolutely performance tradeoffs in that decision and, if you do a lot of development against postgresql, those tradeoffs should influence how you design databases. The author then cherry picked the 'worst case' case, large unconstrained updates.
Hmm... I was wondering about that - even though he stressed that there
was (paraphrasing) no right or wrong - just different design
decisions!
> The article is a bit of a cheezy dig on postgres. Another example is the complaint about autonomous transactions with another cherry picked example to make postgres look back. In the real world, these would not matter much, and can be worked around (if you want to see my take on how to deal with it, see here: https://github.com/leaselock/pgasync).
OK - so, I was wrong in my original assumption that somehow (and it
wasn't simply because of the phraseology - sweep vs vacuum) I thought
that PG and FB had a similar MVCC implementation vs. Oracle and MySQL
(InnoDB) (and OrioleDB). I'll do a deep dive into their docco and see
what they actually do! I'm actually very interested in the
benchmarking side of database technology - but I do know the old adage
- there are lies, damned lies, statistics and *_then_* there are
database benchmarks (as seen with the link I posted!).Sure. I think you'll find that postgres approach to MVCC is somewhat unusual relative to other players in this space, which is to write 'old' records or changes in a rollback log; if the transaction commits it is discarded but if it rolls back, the rollback log is written back to the heap. This makes rollbacks potentially very painful. I suspect the postgres approach can also do better in cases of highly contended records, but that's just a guess.For small (one or a small number of records) updates, the approach doesn't make a whole lot of difference especially if you are aware of and exploit HOT. For very large updates however, it absolutely does, and one might try to avoid them using various strategies. I very much appreciate fast rollbacks though.merlinmerlin
В списке pgsql-general по дате отправления: