Mike Broers writes:
> This is 9.5, sorry I didnt mention that in the initial post.
Hmm, that's odd then.
> I am guessing the issue is that the secondary non-indexed criteria is a
> search through a jsonb column?
Doubt it; it should have considered the plan you are thinking of anyway.
Maybe it d
This is 9.5, sorry I didnt mention that in the initial post. I am guessing
the issue is that the secondary non-indexed criteria is a search through a
jsonb column?
Let me know if I can provide any additional info, as I stated I am working
around it with a subquery at the moment. This seems like i
Mike Broers writes:
> Hello, I am curious about the performance of queries against a master table
> that seem to do seq scans on each child table. When the same query is
> issued at a partition directly it uses the partition index and is very
> fast.
What PG version is that? For me, everything
nan
>>
>>
>>
>> --
>> *From:* pgsql-performance-ow...@postgresql.org <
>> pgsql-performance-ow...@postgresql.org> on behalf of Mike Broers <
>> mbro...@gmail.com>
>> *Sent:* Wednesday, September 21, 2016 12:
uld help, but its just my wish.
>
>
>
> Regards,
> Ganesh Kannan
>
>
>
> --
> *From:* pgsql-performance-ow...@postgresql.org postgresql.org> on behalf of Mike Broers
> *Sent:* Wednesday, September 21, 2016 12:53 PM
> *To:* pgsql-performance@postgresql.org
d help, but its just my wish.
Regards,
Ganesh Kannan
From: pgsql-performance-ow...@postgresql.org
on behalf of Mike Broers
Sent: Wednesday, September 21, 2016 12:53 PM
To: pgsql-performance@postgresql.org
Subject: [PERFORM] query against single partition uses
Hello, I am curious about the performance of queries against a master table
that seem to do seq scans on each child table. When the same query is
issued at a partition directly it uses the partition index and is very
fast.
The partition constraint is in the query criteria. We have non overlappin
