"Huang, Suya" writes:
> I've got a query as below, it runs several times with different execution
> plan and totally different execution time. The one using hash-join is slow
> and the one using semi-hash join is very fast. However, I have no control
> over the optimizer behavior of PostgreSQL
Hi buddies,
I've got a query as below, it runs several times with different execution plan
and totally different execution time. The one using hash-join is slow and the
one using semi-hash join is very fast. However, I have no control over the
optimizer behavior of PostgreSQL database. Or, do I
On 15.5.2014 06:18, Craig James wrote:
> Day and night, the postgres stats collector process runs at about 20
> MB/sec output. vmstat shows this:
>
> $ vmstat 2
> procs ---memory-- ---swap-- -io -system--
> cpu
> r b swpd free buff cache si sobi
On Thu, May 15, 2014 at 9:35 AM, Scott Marlowe wrote:
> OK so we have a query that does OK in 8.4, goes to absolute crap in
> 9.2 and then works great in 9.3. Thing is we've spent several months
> regression testing 9.2 and no time testing 9.3, so we can't just "go
> to 9.3" in an afternoon. But w
Scott Marlowe writes:
> OK so we have a query that does OK in 8.4, goes to absolute crap in
> 9.2 and then works great in 9.3. Thing is we've spent several months
> regression testing 9.2 and no time testing 9.3, so we can't just "go
> to 9.3" in an afternoon. But we might have to. 9.2 seems hopel
OK so we have a query that does OK in 8.4, goes to absolute crap in
9.2 and then works great in 9.3. Thing is we've spent several months
regression testing 9.2 and no time testing 9.3, so we can't just "go
to 9.3" in an afternoon. But we might have to. 9.2 seems hopelessly
broken here.
The query l
Your answer seemed to get the point.
index on telegram_id(type=integer) column can't be used for the filter
condition below
because type mismatches.
((telegram_id)::numeric = ANY ('{66484,132362}'::numeric[]))"
> Date: Thu, 15 May 2014 17:31:10 +0900
> Subj
hi
i think the telegram_id's type should be integer.
please change telegram_id to numeric and try to run the the following sql.
the index should be used.
explain SELECT md.*
FROM measure_data md
where telegram_id in (trunc(66484.2),trunc(132362.1 ))
2014-05-15 17:28 GMT+09:00 changchao :
Hello
we had similar issue - you can try to move statfile to ramdisc
http://serverfault.com/questions/495057/too-much-i-o-generated-by-postgres-stats-collector-process
Regards
Pavel Stehule
2014-05-15 6:18 GMT+02:00 Craig James :
> Day and night, the postgres stats collector process runs at
On May 14, 2014 9:19 PM, "Craig James" wrote:
>
> Day and night, the postgres stats collector process runs at about 20
MB/sec output. vmstat shows this:
>
> $ vmstat 2
> procs ---memory-- ---swap-- -io -system--
cpu
> r b swpd free buff cache si so
Interestingly,adding type cast made postgresql wiser.
Anyone knows the reason?
1.no type cast
SELECT md.*
FROM measure_data md
where telegram_id in (trunc(66484.2),trunc(132362.1 ))
"Seq Scan on measure_data md (cost=0.00..459455.40 rows=205546 width=28)
(actual time=77.144..6458.870 row
11 matches
Mail list logo
