MirrorX wrote:
> default_statistics_target is set to (default) 100 and there no
> special statistics per-column
> in absolute units i can see the same query having similar stats to
> these:
> parse -> 600 ms
> bind -> 300 ms
> execute -> 50 ms
How did you determine those timings?
> the que
On 28/12/2011 19:07, Claudio Freire wrote:
> On Wed, Dec 28, 2011 at 3:02 PM, Matteo Beccati wrote:
>> The query eventually completed in more than 18h. For comparison a normal
>> run doesn't take more than 1m for that specific step.
>>
>> Do you think that bad stats and suboptimal plan alone could
On Wed, Dec 28, 2011 at 3:02 PM, Matteo Beccati wrote:
> The query eventually completed in more than 18h. For comparison a normal
> run doesn't take more than 1m for that specific step.
>
> Do you think that bad stats and suboptimal plan alone could explain such
> a behaviour?
Did you get the exp
Hi,
> A rather long import process is stuck since ~12hrs on a query that
> normally returns in a few seconds or minutes. Kust like to OP there's
> almost no activity on the box, only a single postgres process at 100% CPU.
>
> Two separate queries, (although similar) have triggered the issue, and
On Dec 27, 2011, at 1:12 PM, Tom Lane wrote:
> Jim Crate writes:
>> My question is why does it do a seq scan when it flattens this
>> subquery into a JOIN?
>
> Because it thinks there will be 3783 rows out of the msg scan, which if
> true would make your desired nestloop join a serious loser. Y
Hi,
> I'm also trying an EXPLAIN ANALYZE for the SELECT part, but it seems to
> take a while too and is seemingly calling only gettimeofday.
An update on this. Apart from gettimeofday calls, which I filtered out
when logging, I've seen about 80 lseeks recorded every 1h10m (each 1us
apart):
2011-
Hi everyone,
On 28/10/2011 02:32, Tom Lane wrote:
> =?ISO-8859-1?Q?S=F6ren_Meyer-Eppler?= writes:
>> A fairly complex insert query on an empty destination table will run for
>> an indefinite amount of time (we waited literally days for the query to
>> complete). This does not happen every time
'
27.12.2011 20:13 пользователь "Tom Lane" написал:
>
> Jim Crate writes:
> > My question is why does it do a seq scan when it flattens this
> > subquery into a JOIN?
>
> Because it thinks there will be 3783 rows out of the msg scan, which if
> true would make your desired nestloop join a serious
