iracic

UN alarm about human rights violations https://www.ohchr.org/en/press-releases/2024/02/israelopt-un...

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?

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.

Handling requests can be tricky. Support site is very useful (althrough not a best example of user interface). Usually, you do not want to put your important stuff on first version of some release. Also new features, as somewhere said, are as some good wine - you need to give them some time to have a good use of them.

> You need a team of DBA That surprises me any time I hear. Do you think you would need less people using some other RDBMS ?

JDBC driver is actually very good. How would you improve it?

openshift

I thought ratio based tuning is old-fashioned.

You should write tests first.