Sergey Burladyan writes:
> show maintenance_work_mem ;
> maintenance_work_mem
> --
> 128MB
> create table a (i1 int, i2 int, i3 int, i4 int, i5 int, i6 int);
> insert into a select n, n, n, n, n, n from generate_series(1, 10) as n;
> create index arr_gin on a using gin (
example:
select version();
version
PostgreSQL 8.3.6 on i486-pc-linux-gnu, compiled by GCC gcc-4.3.real (Debian
4.3.3-3) 4.3.3
show maintenance_work_mem ;
main
Brian Cox writes:
> This is a java app. A thread dump reveals that these 5 threads are all
> asleep on a socket read to postgres (see below).
It seems clear that what you've got isn't a performance problem.
May I suggest taking it to pgsql-jdbc? The folk there are more likely
to be able to help
Scott Marlowe writes:
> On Mon, Mar 23, 2009 at 2:25 PM, Brian Cox wrote:
>> This generates and executes a single SQL insert. Since, as you point out,
>> postgres seems to think that this transaction isn't doing anything,
>> it's hard to figure out what the read is doing.
> Might you have a fire
David Wilson [david.t.wil...@gmail.com] wrote:
How many indexes are there on ts_stats_transset_user_daily?
10:
create index ts_stats_transet_user_daily_DayIndex on
ts_stats_transet_user_daily (ts_day);
create index ts_stats_transet_user_daily_HourIndex on
ts_stats_transet_user_daily (ts_hour)
Scott Marlowe [scott.marl...@gmail.com] wrote:
Might you have a firewall that's killing the connections? What does
netstat -an on the client side say about these connections?
I don't think so: 1) app and postgres are on the same machine and 2)
this has been the set up for months and I don't thi
On Mon, Mar 23, 2009 at 2:25 PM, Brian Cox wrote:
> Tom Lane [...@sss.pgh.pa.us] wrote:
>>
>> pg_stat_activity says those five threads are doing nothing except
>> sitting around with open transactions. You sure you don't have a bug on
>> the application side?
>>
>> regards,
Tom Lane [...@sss.pgh.pa.us] wrote:
pg_stat_activity says those five threads are doing nothing except
sitting around with open transactions. You sure you don't have a bug on
the application side?
regards, tom lane
This is a java app. A thread dump reveals that these 5
Brian Cox writes:
> The application log shows that 99652 rows are being inserted into
> relation ts_stats_transet_user_daily. 5 threads are doing the inserts.
pg_stat_activity says those five threads are doing nothing except
sitting around with open transactions. You sure you don't have a bug
Robert Haas wrote:
On Mon, Mar 23, 2009 at 1:08 PM, Anne Rosset wrote:
enable_nestloop = off
That may be the source of your problem. Generally setting enable_* to
off is a debugging tool, not something you ever want to do in
production.
...Robert
Thanks Robert. It seems to have
On Mon, Mar 23, 2009 at 3:34 PM, Brian Cox wrote:
> The application log shows that 99652 rows are being inserted into relation
> ts_stats_transet_user_daily. 5 threads are doing the inserts. The schema is
> lengthy, but it has a synthetic primary key (ts_id int8 not null) and the
> following const
The application log shows that 99652 rows are being inserted into
relation ts_stats_transet_user_daily. 5 threads are doing the inserts.
The schema is lengthy, but it has a synthetic primary key (ts_id int8
not null) and the following constraints:
alter table ts_stats_transet_user_daily add co
On Mon, Mar 23, 2009 at 1:08 PM, Anne Rosset wrote:
> enable_nestloop = off
That may be the source of your problem. Generally setting enable_* to
off is a debugging tool, not something you ever want to do in
production.
...Robert
--
Sent via pgsql-performance mailing list (pgsql-performance@p
Tom Lane wrote:
Robert Haas writes:
On Fri, Mar 20, 2009 at 1:16 PM, Anne Rosset wrote:
The db version is 8.2.4
Something is wrong here. How can setting enable_seqscan to off result
in a plan with a far lower estimated cost than the original plan?
Planner bug no
Romuald Brunet writes:
> After some investigation, we found out that the PostgreSQL server
> (8.1) changed the execution plan (I'm assuming because the number of
> rows increased).
The problem seems to be that the estimate for the number of rows fetched
from dc_post changed drastically --- it was
Romuald Brunet wrote:
> The statistics are at the default value everywhere (10)
Try setting that to 100 and running ANALYZE.
The small size of the sample with the default of 10 happened to land
you with a bad estimate this time. (If the numbers it has were
actually representative of the data
Hello all.
To our surprise this morning, we found a query that used to return
it's result in about 50 ~ 100ms now take about 7.000ms to run.
After some investigation, we found out that the PostgreSQL server
(8.1) changed the execution plan (I'm assuming because the number of
rows increased).
Sin
17 matches
Mail list logo
