Brian Cox writes:
> these queries are still running now 27.5 hours later... These queries
> are generated by some java code and in putting it into a test program so
> I could capture the queries, I failed to get the id range correct --
> sorry for wasting your time with bogus data. Below is the
On Thu, Jun 18, 2009 at 6:16 PM, Brian Cox wrote:
> Grzegorz Jakiewicz [gryz...@gmail.com] wrote:
>
>> this might be quite bogus question, just a hit - but what is your
>> work_mem set to ?
>> Guys, isn't postgresql giving hudge cost, when it can't sort in memory ?
>>
> work_mem = 64MB
>
try incr
Grzegorz Jakiewicz [gryz...@gmail.com] wrote:
this might be quite bogus question, just a hit - but what is your
work_mem set to ?
Guys, isn't postgresql giving hudge cost, when it can't sort in memory ?
work_mem = 64MB
--
Sent via pgsql-performance mailing list (pgsql-performance@postgresql.org
On Thu, Jun 18, 2009 at 6:06 PM, Brian Cox wrote:
> these queries are still running now 27.5 hours later... These queries are
> generated by some java code and in putting it into a test program so I could
> capture the queries, I failed to get the id range correct -- sorry for
> wasting your time
Tom Lane [...@sss.pgh.pa.us] wrote:
Yup. So according to those stats, all ts_id values fall in the range
61 .. 6000250068. It's no wonder it's not
expecting to find anything between 0 and 10. I think maybe you
forgot to re-analyze after loading data ... although thi
Brian Cox writes:
> Tom Lane [...@sss.pgh.pa.us] wrote:
>> OK, so what's the entry for column ts_id?
> Is this what you requested? Brian
Yup. So according to those stats, all ts_id values fall in the range
61 .. 6000250068. It's no wonder it's not
expecting to find anyt
Tom Lane [...@sss.pgh.pa.us] wrote:
OK, so what's the entry for column ts_id?
Is this what you requested? Brian
cemdb=# select * from pg_stats where
tablename='ts_stats_transetgroup_user_daily' and attname = 'ts_id';
schemaname |tablename | attname | null_frac |
avg_
Brian Cox writes:
> Tom Lane [...@sss.pgh.pa.us] wrote:
>> ... Do you have ANALYZE stats for
>> ts_stats_transetgroup_user_daily at all (look in pg_stats)?
> postgres 8.3.5. Yes, here's a count(*) from pg_stats:
> 186
OK, so what's the entry for column ts_id?
regard
Tom Lane [...@sss.pgh.pa.us] wrote:
This seems like kind of a stupid plan anyway (which PG version was this
exactly?) but certainly the big issue is the catastrophically bad
rowcount estimate for the indexscan. Do you have ANALYZE stats for
ts_stats_transetgroup_user_daily at all (look in pg_sta
Brian Cox writes:
> Tom Lane [...@sss.pgh.pa.us] wrote:
>> Um, are you sure that is the query that PID 7397 is running? It doesn't
>> match your previous pg_stat_activity printout, nor do I see anything
>> about partitioning by PKs.
> Umm, indeed. I had to construct the query by hand and left ou
Tom Lane [...@sss.pgh.pa.us] wrote:
Um, are you sure that is the query that PID 7397 is running? It doesn't
match your previous pg_stat_activity printout, nor do I see anything
about partitioning by PKs.
Umm, indeed. I had to construct the query by hand and left out the
partition part. Here's
Brian Cox writes:
> Here's the explain and a current strace and lsof. The strace shows even
> less I/O activity.
> cemdb=# explain select * from ts_stats_transetgroup_user_daily a where
> a.ts_id in (select b.ts_id from ts_stats_transetgroup_user_daily
> b,ts_stats_transet_user_interval c, ts_
Tom Lane [...@sss.pgh.pa.us] wrote:
That is a pretty odd trace for a Postgres backend; apparently it's
repeatedly acquiring and releasing a meg or two worth of memory, which
is not very normal within a single query. Can you tell us more about
the query it's running? An EXPLAIN plan would be par
Brian Cox writes:
> [r...@rdl64xeoserv01 log]# strace -p 7397
> Process 7397 attached - interrupt to quit
> munmap(0x95393000, 1052672) = 0
> munmap(0x95494000, 528384) = 0
> munmap(0x95515000, 266240) = 0
> brk(0x8603000) = 0x8603000
14 matches
Mail list logo
