this issue persists in
14.
Changing my main query to the above structure significantly improved
performance - I was previously having lots of performance issues when
aggregation tasks ran and dropped partitions etc.
I posted about this here:
https://www.postgresql.org/message-id/84101021-8B67-45AD-83F2-A3C8F0AA4BEE%40daork.net
--
Nathan Ward
/07/2022, at 6:20 PM, Nathan Ward wrote:
>
>>
>> On 11/07/2022, at 4:05 PM, Justin Pryzby wrote:
>>
>> On Mon, Jul 11, 2022 at 03:21:38PM +1200, Nathan Ward wrote:
>>>> Note that postgres doesn't automatically analyze parent tables, so you
>>>
> On 11/07/2022, at 4:05 PM, Justin Pryzby wrote:
>
> On Mon, Jul 11, 2022 at 03:21:38PM +1200, Nathan Ward wrote:
>>> Note that postgres doesn't automatically analyze parent tables, so you
>>> should
>>> maybe do that whenever the data changes enough
> On 11/07/2022, at 2:05 AM, Justin Pryzby wrote:
>
> On Sun, Jul 10, 2022 at 04:55:34PM +1200, Nathan Ward wrote:
>> I am running Postgres 13 on CentOS 7, installed from the yum.postgresql.org
>> <http://yum.postgresql.org/> repo.
>
> It doesn't so
urs, so it’s hard to differentiate between cause and
symptoms in those metrics.
I have bumped up effective_cache_size from default of 4GB to 16GB since this
last happened - but given IO doesn’t appear to be an issue, I don’t think this
will have too much effect.
--
Nathan Ward
