On Tuesday 05 June 2007 10:34:04 Douglas J Hunley wrote:
> On Monday 04 June 2007 17:11:23 Gregory Stark wrote:
> > Those plans look like they have a lot of casts to text in them. How have
> > you defined your indexes? Are your id columns really text?
>
> project table:
> Indexes:
> "project_pk
Find the attached Postgres.conf file. I am using 8.1 Version in Lab.
I haven't done any changes to this conf file to improve the performance.
What are the attributes needs to be modified in the conf file to improve the
performance?
I am looking forward for your assistance.
Regards,
Hanu
On Monday 04 June 2007 17:11:23 Gregory Stark wrote:
> Those plans look like they have a lot of casts to text in them. How have
> you defined your indexes? Are your id columns really text?
project table:
Indexes:
"project_pk" PRIMARY KEY, btree (id)
"project_path" UNIQUE, btree (path)
rol
On Monday 04 June 2007 17:17:03 Heikki Linnakangas wrote:
> And did you use the same encoding and locale? Text operations on
> multibyte encodings are much more expensive.
The db was created as:
createdb -E UNICODE -O
--
Douglas J Hunley (doug at hunley.homeip.net) - Linux User #174778
http://
On Sat, Jun 02, 2007 at 09:13:32AM -0400, Douglas J Hunley wrote:
> Hello great gurus of performance:
> Our 'esteemed' Engr group recently informed a customer that in their testing,
> upgrading to 8.2.x improved the performance of our J2EE
> application "approximately 20%", so of course, the cust
Gregory Stark wrote:
Those plans look like they have a lot of casts to text in them. How have you
defined your indexes? Are your id columns really text?
And did you use the same encoding and locale? Text operations on
multibyte encodings are much more expensive.
--
Heikki Linnakangas
Ent
Those plans look like they have a lot of casts to text in them. How have you
defined your indexes? Are your id columns really text?
And you don't have a 7.4 install around to compare the plans do you?
--
Gregory Stark
EnterpriseDB http://www.enterprisedb.com
-
On Saturday 02 June 2007 11:21:41 Michael Fuhr wrote:
> If you post an example query and the
> EXPLAIN ANALYZE output then we might be able to see if the slowness
> is due to query plans.
Query 1:
(SELECT
project.path AS rbac_project_path_string,
role_operation.resource_name AS rbac_
Douglas J Hunley wrote:
> On a side note, is there any real benefit to using autovacuum over a
> periodically scheduled vacuum? I ask because we have the latter already coded
> up and cron'd and it seems to keep things fairly optimized.
No, not really. Maybe autovacuum could get to specific hi
On Sunday 03 June 2007 18:30:17 Greg Smith wrote:
> To be equivalent to the 7.4 config the 8.2 config would need:
I've taken all the wonderful advise offered thus far, and put the attached
into use. Our initial testing shows a 66% improvement in page load times for
our app. I have the customer b
On Sun, 2007-06-03 at 23:17 -0400, Tom Lane wrote:
> Douglas J Hunley <[EMAIL PROTECTED]> writes:
> > On Saturday 02 June 2007 11:25:11 Tom Lane wrote:
> >> Another thing that seems strange is that the 8.2 config file does not
> >> seem to have been processed by initdb --- or did you explicitly com
ane; pgsql-performance@postgresql.org
Subject: Re: [PERFORM] upgraded to pgsql 8.2.4, getting worse
performance then 7.4.x
On Sunday 03 June 2007 16:39:51 Luke Lonergan wrote:
> When you initdb, a config file is edited from the template by initdb to
> reflect your machine config.
Douglas J Hunley wrote:
On Sunday 03 June 2007 16:39:51 Luke Lonergan wrote:
When you initdb, a config file is edited from the template by initdb to
reflect your machine config.
I didn't realize that. I'll have to harass the rest of the team to see if
someone overwrote that file or not. In th
On Sunday 03 June 2007 16:39:51 Luke Lonergan wrote:
> When you initdb, a config file is edited from the template by initdb to
> reflect your machine config.
I didn't realize that. I'll have to harass the rest of the team to see if
someone overwrote that file or not. In the interim, I did an 'ini
Douglas J Hunley <[EMAIL PROTECTED]> writes:
> On Saturday 02 June 2007 11:25:11 Tom Lane wrote:
>> Another thing that seems strange is that the 8.2 config file does not
>> seem to have been processed by initdb --- or did you explicitly comment
>> out the settings it made?
> I don't understand thi
On Sun, 3 Jun 2007, Douglas J Hunley wrote:
commit_delay = 2
commit_siblings = 3
Those are based on a thread their (non-pgsql) DBA found online. I'm perfectly
willing to discount him if so advised.
Those likely came indirectly from the otherwise useful recommendations at
http://www.w
Cc: pgsql-performance@postgresql.org
Subject:Re: [PERFORM] upgraded to pgsql 8.2.4, getting worse
performance then 7.4.x
On Saturday 02 June 2007 11:25:11 Tom Lane wrote:
> Another thing that seems strange is that the 8.2 config file does not
> seem to have been processed by
On Saturday 02 June 2007 11:25:11 Tom Lane wrote:
> Another thing that seems strange is that the 8.2 config file does not
> seem to have been processed by initdb --- or did you explicitly comment
> out the settings it made?
I don't understand this comment. You are saying 'initdb' will make changes
On Saturday 02 June 2007 11:21:41 Michael Fuhr wrote:
> After the restore, did you ANALYZE the entire database to update
> the planner's statistics? Have you enabled autovacuum or are you
> otherwise vacuuming and analyzing regularly? What kind of queries
> are slower than desired? If you post a
Michael Fuhr wrote:
> On Sat, Jun 02, 2007 at 09:13:32AM -0400, Douglas J Hunley wrote:
>> Our 'esteemed' Engr group recently informed a customer that in their
>> testing,
>> upgrading to 8.2.x improved the performance of our J2EE
>> application "approximately 20%", so of course, the customer th
Douglas J Hunley <[EMAIL PROTECTED]> writes:
> ... We dumped their db, removed pgsql, installed the 8.2.4
> rpms from postgresql.org, did an initdb, and the pg_restored their data. It's
> been about a week now, and the customer is complaining that in their testing,
> they are seeing a 30% /decre
Douglas J Hunley wrote:
Hello
The DB server in question does nothing else, is running CentOS 4.5, kernel
2.6.9-55.ELsmp. Hyperthreading is disabled in the BIOS and there are 2 Xeon
3.4Ghz cpus. There is 8Gb of RAM in the machine, and another 8Gb of swap.
After a very quick read of your con
On Sat, Jun 02, 2007 at 09:13:32AM -0400, Douglas J Hunley wrote:
> Our 'esteemed' Engr group recently informed a customer that in their testing,
> upgrading to 8.2.x improved the performance of our J2EE
> application "approximately 20%", so of course, the customer then tasked me
> with upgradin
Hello great gurus of performance:
Our 'esteemed' Engr group recently informed a customer that in their testing,
upgrading to 8.2.x improved the performance of our J2EE
application "approximately 20%", so of course, the customer then tasked me
with upgrading them. We dumped their db, removed pgsq
24 matches
Mail list logo
