Glyn Astill writes:
>> From: Tom Lane
>> The problem will probably go away by itself as your table grows, but
>> if you don't want to wait, you might want to reflect on which of the index
>> columns might be (partially?) functionally dependent on the other columns,
>> and whether you could redesi
- Original Message -
> From: Tom Lane
> To: Glyn Astill
> Cc: Pgsql-performance
> Sent: Thursday, 26 November 2015, 16:44
> Subject: Re: [PERFORM] Index scan cost calculation
>
> Glyn Astill writes:
>> Using pg 9.4.5 I'm looking at a table set up by a 3rd party application
> and try
Glyn Astill writes:
> Using pg 9.4.5 I'm looking at a table set up by a 3rd party application and
> trying to figure out why a particular index is being chosen over another for
> updates/deletes.
> From what I can see the reason is that plans using either index have the same
> exactly the same
- Original Message -
> From: Glyn Astill
> To: Pgsql-performance
> Sent: Thursday, 26 November 2015, 16:11
> Subject: [PERFORM] Index scan cost calculation
>
> Hi All,
>
> Using pg 9.4.5 I'm looking at a table set up by a 3rd party application and
> trying to figure out why a particul
Hi All,
Using pg 9.4.5 I'm looking at a table set up by a 3rd party application and
trying to figure out why a particular index is being chosen over another for
updates/deletes.
>From what I can see the reason is that plans using either index have the same
>exactly the same cost. So rather I'
Adam Brusselback wrote:
> I appreciate the response Tom, and you are correct that the workaround would
> not work in my case.
>
> So no index expressions can return the their value without recomputing
> without that work around? I
> learn something new every day it seems.
> Thank you for the al
