On Mon, Jul 23, 2012 at 4:07 PM, Tom Lane <tgl@sss.pgh.pa.us> wrote:
> Daniele Varrazzo <daniele.varrazzo@gmail.com> writes:
>> Since "big" was sharded, the query plan results in something like:
>> [ugly]
>
> [ squint... ] 9.1 certainly ought to be able to find a smarter plan for
> such a case. For instance, if I try this on 9.1 branch tip:
> [good]
>
> You have evidently got enable_seqscan turned off, so I wonder whether
> the cost penalties applied by that are swamping the estimates. Do you
> get any better results if you re-enable that?
Hello Tom, thank you for your help.
Actually, I don't know what to say. seqscan were most likely enabled
when the problem showed up. I may have disabled it for testing in my
session and the plan I've copied may have been generated with disabled
seqscan, but the original problem (that query never completing) was
reported in different sessions by different people, so the only
possibility was that seqscans were disabled in the config file...
which I have been confirmed was not the case. I hadn't tested in my
session whether they were disabled before explicitly disabling them
for testing.
Matter of fact, after reading your reply, I've tested the query
again... and it was fast, the plan being the nested loop of your
example. :-\ What can I say, thank you for your radiation...
I've tried reverting other schema changes we performed yesterday but
I've not been able to reproduce the original slowness. In case we find
something that may be any useful to postgres I'll report it back.
Have a nice day,
-- Daniele