iracic

You can't check complex cases with that.

Yes, some are able to verify that execution plan already exists (saved in gather run or by explicit command) before replaning. Also you can group them with one label and activate only when needed.

I guess that there must be a good number of people who would use it in PostgreSQL. Anybody analyzed previous tries to implement it?

Hi, yes, I assumed it would be the case. And it is not always easy to explain word terminations/cases. Especialy if you do not use it regularly or is limited to family interactions. I would guess your pronouncian might come from either some parts of Lika/Dalmatia or Bosnian part closer to Croatia. Is it the case?

It would be rather jedanaest, dvanaest, trinaest (at least in Croatian) - your version sounds how it is shortened in pronounciation in some regions. Also šezdeset with "z".

There are lot more here. Idea is to put chances on your side in some possibly long and time constrained migration. How do you handle run that stops in the middle? How to avoid rerun of long running process that finished correctly but exited in step after? How do you revert the change to come to some previous point in time in case it is really really needed? And all that in some environment you maybe have no access but need to guide other person to act with steps defined in advance? How do you handle if some error is fatal to stop the process and other just pass with warning printed? Need to run some actions on each deployment? How do you log and verify what steps were run before? What process to use when multiple teams need to deploy to different environments and maybe different database types (different syntax, different rollback strategies)?

Access method is just part of the story. Same index may be accessed in different ways, you might also want to combine them. Sometimes you may change table join order to see how it estimates (or executes). Usually there are two parts 1) cost and reasoning for some estimation 2) how it executes (timings, resource usage, locks/contention)

Some good points in article. There are some things that may need more attention. 1) Update from another table is not safe as it should be (in case of multiple values, final value will be sort of random) 2) Schemas as namespace separators (grouping tables inside database) 3) Extern join syntax in Oracle is actually more vulnerable (in case of error in multicolumn syntax it fallbacks to normal join). So, it's not better or easier - it is just created before standard JOIN existed. 4) Crucial difference how buffer-vs-filesystem cache works 5) Miss of plan stability - no solution out of the box in standard installation 6) Batch operation (in)efficiency 7) Pros/cons in undo/rollback handling [likely some more that can't think of right now]

It is possible to put database in state that is "ready" for snapshot, pushing changes to disk and sort of freezing I/O during snapshot.

Hi, Can you share more details about #1 market position ?

PostgreSQL, Golang, VueJS, old fashioned VMs

>> The downside is that commits and rollbacks are slower

Commit is not slower. Some part of the work is delayed, ex first SELECT after change may be involved to check & update row status in data block by peeking transaction state in UNDO. Huge rollback is the real pain and something you don't want to do and in some situations you would prefer to go UNDO-less.

Seems promising. Thank you for info.

Thank you for reply. Did you test some other sites before going to Google Translate?