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]
>> 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.
You can also record and save plan you are happy with. So, no need to fix hints in code. It is more flexible and may be practical when you upgrade version or environment changes.
There is. When you need to treat your data without network delays. When performance is essential. When you can't express it efficiently with non-procedural SQL or need to have access with several technologies (can think of it as service on db level).
Depending of environments, deploying changes can be much easier than patching app side.
As someone who like down-to-earth first approach, I find it strange that reading about doing old-school way sounds, actually, refreshing. It would be interesting for anybody who builds starting from small blocks, do you have some blog about ongoing stuff?
I use it for some time. No need to challenge your eyes with long lines or json values anymore.
This kind of result presentation should be in each command line client. Very very useful.
Dynamicaly adding filters or parts of the query, be able to have different parties to construct query, do transformations, replacing objects,... that would be great. And having it in well known, standard format and supported in languages, and have execution plans the similar way, that would be the dream... That would really simplify the life.
Happy user of ux32vd here for 3-4 years. i7, upgraded ram to 10Gb. Disk is slower than it could be, short batery life ~3h. All in all I would buy it again.