Re: Elastic Search much faster at statistics?
| От | Miles Elam |
|---|---|
| Тема | Re: Elastic Search much faster at statistics? |
| Дата | |
| Msg-id | CAALojA_PpQJsHgfAtxOg0MaT2MB4AWc23tY6MZ23az-Ocj4R6Q@mail.gmail.com обсуждение исходный текст |
| Ответ на | Elastic Search much faster at statistics? (Guyren Howe <guyren@gmail.com>) |
| Список | pgsql-general |
Not enough information. It looks far more like he's testing Ruby's support for ElasticSearch vs ActiveRecord rather than ES vs PostgreSQL. Caching could definitely hold a role but also choice of indexes. If ES is calculating some aggregate info on the fly, the equivalent in PG would be a stats table updated by trigger or as part of a regularly refreshed materialized view. That said, if ES does some of that aggregation out of the box, the convenience by default is compelling for some.
There are indeed cases where a caching engine will outperform a general purpose data management engine. There are many cases where ACID requirements preclude the use of a dedicated search engine. Use the right tool for the job, and for a sufficiently large scale, use multiple tools.
On Mon, Jul 8, 2019 at 9:54 AM Guyren Howe <guyren@gmail.com> wrote:
I find this… surprising. Caching?
В списке pgsql-general по дате отправления: