Re: possibilities for SQL optimization
От | Michael Lewis |
---|---|
Тема | Re: possibilities for SQL optimization |
Дата | |
Msg-id | CAHOFxGoNMVSuHs=VFkHUw5bDwkX12k30dYCy8d3WnFwxALpU_A@mail.gmail.com обсуждение исходный текст |
Ответ на | Re: possibilities for SQL optimization (Olivier Gautherot <ogautherot@gautherot.net>) |
Ответы |
Re: possibilities for SQL optimization
|
Список | pgsql-general |
My other thought was to range partition by pixelID + brin index.
I would expect brin index to be INSTEAD of partitioning. You didn't share buffer hits, which I expect were 100% on the subsequent explain analyze runs, but the index scan may still be faster if the planner knows it only needs to scan a few small indexes on one, or a few, partitions.
What sort of growth do you see on this table? Is future scalability a significant concern, or is the problem just that 40-300ms for this select is unacceptable?
set effective_io_concurrency = 200;
/* select query */
reset effective_io_concurrency; /* if doing other things in the same session and wanting to revert to default behavior, else just disconnect */
В списке pgsql-general по дате отправления: