Re: possibilities for SQL optimization

[Michael Lewis <mlewis@xxxxxxxxxxx>]

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?

https://www.postgresql.org/docs/current/runtime-config-resource.html#RUNTIME-CONFIG-RESOURCE-ASYNC-BEHAVIOR

Have you tuned effective_io_concurrency? The documentation says "this setting only affects bitmap heap scans" and nearly all the time is there. If it is still set to 1 as default, then increasing to 200 or perhaps more might be prudent when on SSD or other memory backed storage. You don't even need to change the server config defaults for testing the impact-

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 */