I reported this in the pgsql-general list and was instructed to send
the analaze outputs here.
have this query it runs reasonably quickly (but should be quicker IMHO)
SELECT "consolidated_urls".* FROM "consolidated_urls" INNER JOIN "topical_urls"
ON "consolidated_urls".id = "topical_urls".conso
Tim Uckun writes:
> I reported this in the pgsql-general list and was instructed to send
> the analaze outputs here.
This isn't a bug, it's just a poor choice of plan based on a bad
statistical estimate. The planner is estimating that there are 2643
rows having domain_id = 157, when actually the
Both queries use the same row's estimation and cost is comparable. But
execution time differs huge: 0.044s and 3100s. I think that the cost
of backward index scan is too small.
On 1/15/11, Tom Lane wrote:
> Tim Uckun writes:
>> I reported this in the pgsql-general list and was instructed to send
>
> Possibly the table's never been ANALYZEd ... do you have autovacuum
> enabled? If it has been analyzed reasonably recently, then it might be
> necessary to crank up the statistics target to get a better estimate.
> It's difficult to give detailed advice when you haven't mentioned what
> PG ver
The following bug has been logged online:
Bug reference: 5840
Logged by: Karsten Loesing
Email address: karsten.loes...@gmx.net
PostgreSQL version: 8.4.5
Operating system: Mac OS X 10.6 and Debian Lenny
Description:Updating arrays using subscripted assignment results
When I create a database dump from a database with time zone = UTC (my
production machine) and attempt to load it in a database with the
'US/Eastern' time zone (my development machine), pg_restore reports
that the dump violates a check constraint. The constraint uses
date_trunc('day', ) to ensure t
