On Thu, May 12, 2011 at 8:53 AM, Prodan, Andrei
wrote:
>
> @Jeff: thank you for the clear plan interpretation - but I'm afraid I
> don't really understand the second bit:
> 1) I provided the GOOD plan, so we already know what postgres thinks,
> right? (Later edit: guess not. Doesn't work)
> 2) The
Thank you for all the leads.
I've increased stats to 1200 on everything obvious (external_id,
attr_name, attr_value, party_id), and ran ANALYZE, but it didn't help at
all - any other ideas of what else could be going wrong ?
We'll disable preparation, but the thing is it works brilliantly 90% of
t
On Wed, May 11, 2011 at 4:08 AM, Prodan, Andrei
wrote:
>
...
>
>
> The select is as follows:
> prepare ps(varchar,varchar,varchar) as select party.party_id from party,
> big_table where external_id = $1 and party.party_id = big_table.party_id
> and attr_name = $2 and attr_value = $3;
> PREPARE
> e
Shaun Thomas writes:
> On 05/11/2011 06:08 AM, Prodan, Andrei wrote:
>> Index Scan using attr_name_value on big_table (cost=0.00..22.85
>> rows=4 width=7) (actual time=0.176..757.646 rows=914786 loops=1)
> Holy inaccurate statistics, Batman!
> Try increasing your statistics target for attr_name
On 05/11/2011 06:08 AM, Prodan, Andrei wrote:
Index Scan using attr_name_value on big_table (cost=0.00..22.85
rows=4 width=7) (actual time=0.176..757.646 rows=914786 loops=1)
Holy inaccurate statistics, Batman!
Try increasing your statistics target for attr_name and attr_value in
your big t
