Hi Peter,
Many thanks for your response. I tried to cancel the thread, it was
unfortunately stupidity that was the issue. We'd been forced to manually
analyze our tables due to time constraints, and one of the table partitions
read in the query was missed. It was reporting a bitmap index scan o
On Tue, Jul 25, 2017 at 10:34 PM, Nick Brennan wrote:
> Hi,
>
> We have recently promoted our Prod DB slave (2TB) to migrate to new
> hardware, and upgraded from v9.2.9.21 to 9.5.1.6 using pg_upgrade.
>
>
> The upgrade went without incident and we have been running for a week, but
> the optimizer
On Wed, Jul 26, 2017 at 2:05 PM, Peter Geoghegan wrote:
> On Tue, Jul 25, 2017 at 10:34 PM, Nick Brennan wrote:
>> We've added duplicate indexes and analyzing, however the new indexes are
>> still ignored unless we force using enable_seqscan=no or reduce
>> random_page_cost to 2. The query respon
On Tue, Jul 25, 2017 at 10:34 PM, Nick Brennan wrote:
> We've added duplicate indexes and analyzing, however the new indexes are
> still ignored unless we force using enable_seqscan=no or reduce
> random_page_cost to 2. The query response times using the new indexes are
> still as slow when we do
Hi,
We have recently promoted our Prod DB slave (2TB) to migrate to new
hardware, and upgraded from v9.2.9.21 to 9.5.1.6 using pg_upgrade.
The upgrade went without incident and we have been running for a week, but
the optimizer is ignoring indexes on 2 of our largest partitioned tables
causing v
