On Wed, Mar 31, 2010 at 12:11 AM, Brian Cox wrote:
>
> 2010-03-30 18:41:11.685261-07 | select b.ts_id from
> ts_stats_tranunit_user_daily b, ts_stats_tranunit_user_interval c where
> b.ts_transet_incarnation_id = c.ts_transet_incarnation_id and
> b.ts_tranunit_id = c.ts_tranunit_id and b.ts_user
postgres 8.3.5 on RHEL4 update 6
This query starts executing at 18:41:
cemdb=> select query_start,current_query from pg_stat_activity where
procpid=10022; query_start |
current_query
---+-
On Tue, Mar 30, 2010 at 12:30 PM, Faheem Mitha wrote:
> Sure, but define sane setting, please. I guess part of the point is that I'm
> trying to keep memory low, and it seems this is not part of the planner's
> priorities. That it, it does not take memory usage into consideration when
> choosing a
Artiom Makarov writes:
> When temp tables with "on commit delete rows" exists, I can see a
> strange delay at any begin and commit.
A delay at commit is hardly surprising, because each such temp table
requires filesystem operations at commit (basically an "ftruncate").
I don't recall any oper
On thing which I haven't really mentioned in this thread or in my writeup,
is that the planners value for the number of rows in geno is way off base
some of the time. It is around 800 million, it thinks it is 100 million. I
don't know if this is significant or not, or what to do about it.
eg
Ireneusz Pluta wrote:
I am waiting for an ordered machine dedicated to PostgresSQL. It was
expected to have 3ware 9650SE 16 port controller. However, the vendor
wants to replace this controller with MegaRAID SAS 84016E, because, as
they say, they have it on stock, while 3ware would be available
Hi,
I am waiting for an ordered machine dedicated to PostgresSQL. It was
expected to have 3ware 9650SE 16 port controller. However, the vendor
wants to replace this controller with MegaRAID SAS 84016E, because, as
they say, they have it on stock, while 3ware would be available in a few
weeks.
I
On Tue, 30 Mar 2010, Kevin Grittner wrote:
Faheem Mitha wrote:
If you're concerned about memory usage, try reducing work_mem;
you've probably got it set to something huge.
work_mem = 1 GB (see diag.{tex/pdf}).
The point isn't that I'm using so much memory. Again, my question
is, why are
We have a postgres database which accessed by clients app via PL/PGSQL
stored procedures.
For some reasons we use about 25 temp tables "on commit delete rows". It
widely used by our SP. I can see a stramge delay at any “begin” and
“commit”:
2010-03-09 15:14:01 MSK logrus 32102 amber LOG: du
Hi!
We have a postgres database which accessed by clients app via PL/PGSQL
stored procedures ( 8.4.1 on x86_64 ubuntu 8.04 server).
For some reasons we use about 25 temp tables "on commit delete rows".
It widely used by our SP.
When temp tables with "on commit delete rows" exists, I can see a
str
Please don't cc two of the lists here. It makes things difficult for
users who only subscribe to one list or the other who reply--their post
to the other list will be held for moderation. And that's a pain for
the moderators too. In this case, either the pgsql-admin or
pgsql-performance list
You may want to consider performing more frequent vacuums a week or really
considering leveraging autovacuum if it makes sense to your transactions
volume.
Regards,
Husam
-Original Message-
From: Gnanakumar
Sent: Saturday, March 27, 2010 6:06 AM
To: pgsql-ad...@postgresql.org
Faheem Mitha wrote:
>> If you're concerned about memory usage, try reducing work_mem;
>> you've probably got it set to something huge.
>
> work_mem = 1 GB (see diag.{tex/pdf}).
>
> The point isn't that I'm using so much memory. Again, my question
> is, why are these changes affecting memory us
"Gnanakumar" wrote:
> We're using PostgreSQL 8.2.
Newer versions have much improved the VACUUM and CLUSTER features.
You might want to consider upgrading to a later major version.
> I have a question in connection to this question posted by me
> earlier:
>
>
http://archives.postgresql.org/
On Fri, Mar 26, 2010 at 7:57 PM, Richard Yen wrote:
> Note that it is constantly paging in, but never paging out. This would
> indicate that it's constantly reading from swap, but never writing out to it.
> Why would postgres do this? (postgres is pretty much the only thing running
> on this
On Mon, Mar 29, 2010 at 2:00 AM, Tadipathri Raghu wrote:
> I have noticed one more thing here, that if you turn off the fsync and try
> to run the transaction than its breaking the currnet filenode and generating
> another filenode. Is it true that whenever you turn off or on the fsync the
> filen
On 3/30/2010 4:32 AM, Gnanakumar wrote:
Hi,
We're using PostgreSQL 8.2.
I have a question in connection to this question posted by me earlier:
http://archives.postgresql.org/pgsql-performance/2010-03/msg00343.php
In our application, DML operations (INSERT/UPDATE/DELETE) are heavily
performed
On 3/30/2010 6:17 AM, Gnanakumar wrote:
We're using pgpool-II version 2.0.1 for PostgreSQL connection management.
pgpool configurations are:
num_init_children = 450
child_life_time = 300
connection_life_time = 120
child_max_connections = 30
As you recommended, I ran "ps -ax|grep postgres" at al
Hello,
I am waiting for an ordered machine dedicated to PostgresSQL. It was
expected to have 3ware 9650SE 16 port controller. However, the vendor
wants to replace this controller with MegaRAID SAS 84016E, because, as
they say, they have it on stock, while 3ware would be available in a few
wee
We're using pgpool-II version 2.0.1 for PostgreSQL connection management.
pgpool configurations are:
num_init_children = 450
child_life_time = 300
connection_life_time = 120
child_max_connections = 30
As you recommended, I ran "ps -ax|grep postgres" at almost a busy
transaction time and I can fin
On Mon, 29 Mar 2010, randa...@bioinfo.wsu.edu wrote:
WHERE ... lower(n.name) LIKE 'Scaffold:scaffold_163:1000..1199%' ...
I'm sure you noticed that this is never going to return any rows?
Matthew
--
Me... a skeptic? I trust you have proof?
--
Sent via pgsql-performance mailing list (pgsql-p
Hi,
We're using PostgreSQL 8.2.
I have a question in connection to this question posted by me earlier:
http://archives.postgresql.org/pgsql-performance/2010-03/msg00343.php
In our application, DML operations (INSERT/UPDATE/DELETE) are heavily
performed in a day.
I also read about p
22 matches
Mail list logo
