| ▲ | cluckindan 11 hours ago | ||||||||||||||||||||||||||||
”That means a recently acknowledged write may not show up until the next refresh.” Which is why you supply the parameter
in your writes. This forces a refresh and waits for it to happen before completing the request.”schema migrations require moving the entire system of record into a new structure, under load, with no safety net” Use index aliases. Create new index using the new mapping, make a reindex request from old index to new one. When it finishes, change the alias to point to the new index. The other criticisms are more valid, but not entirely: for example, no database ”just works” without carefully tuning the memory-related configuration for your workload, schema and data. | |||||||||||||||||||||||||||||
| ▲ | nkmnz 11 hours ago | parent | next [-] | ||||||||||||||||||||||||||||
It took me years before I started tuning the memory-related configuration of postgres for workload, schema and data, in any way. It "just works" for the first ten thousand concurrent users. | |||||||||||||||||||||||||||||
| |||||||||||||||||||||||||||||
| ▲ | aPoCoMiLogin 5 hours ago | parent | prev [-] | ||||||||||||||||||||||||||||
it's the other way around: `wait_for` waits for the next refresh (there is configurable refresh interval, 1s by default), `refresh: true` forces refresh without waiting for the next refresh interval. the difference is that waiting for refresh assures that the data will be available for search after the "insert" finishes. forcing refresh might be foot gun that will criple the servers. | |||||||||||||||||||||||||||||