On Thu, Apr 16, 2020 at 10:47 AM Michael Lewis wrote:
> 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
>
> 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
n
Hi Chris,
40ms for a select on 302 millions rows sounds reasonable. What I would try
to do is group by binary patterns on pixelId to reduce the number of cases
(use some arithmetics) and use a calculated index but I'm not sure of how
much you would save.
On Thu, Apr 16, 2020 at 4:57 PM Chris Ste
disastrous :)
Planning Time: 7.569 ms
Execution Time: 316969.474 ms
On Thu, Apr 16, 2020 at 9:23 AM Pavel Stehule
wrote:
>
>
> čt 16. 4. 2020 v 16:08 odesílatel Chris Stephens
> napsal:
>
>> PG12
>> RHEL 8
>>
>> I suspect there's little I can do to get the following query to run
>> faster/more
čt 16. 4. 2020 v 16:08 odesílatel Chris Stephens
napsal:
> PG12
> RHEL 8
>
> I suspect there's little I can do to get the following query to run
> faster/more efficiently but thought I'd post to list and confirm.
>
> Caveat: I'm coming from an Oracle background and am extremely wet behind
> ears
PG12
RHEL 8
I suspect there's little I can do to get the following query to run
faster/more efficiently but thought I'd post to list and confirm.
Caveat: I'm coming from an Oracle background and am extremely wet behind
ears w/ respect to postgresql (please be kind :)).
Right now, we can't change
