Re: possibilities for SQL optimization

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