Hi,
Has anyone done any benchmarks to see if PG compiled for the target
CPU (Athlon XP, P4 Xeon, Pentium III, etc) is significantly more
efficient than when compiled for the i386? This should also apply
to Sparc, Alpha, etc.
Yes, more RAM and faster disks are extremely important, but when the
fa
I have the following schema which I have set up, and I have inserted a
bunch of entries into it:
create domain contact_id as integer;
create sequence contact_seq;
create domain street_address as character varying(64);
create domain name as character varying(64);
create domain country as character(
Rajesh Kumar Mallah <[EMAIL PROTECTED]> writes:
> Below are the plans for two cases. I dont know how to read them accurately
> can u please explain them.
Well, they're the same plan, as far as they go. I suppose that the
runtime difference must come from choosing a different plan inside the
most_
You make an interesting distinction that read/write needs more shared
memory. I think this is because if you want to reused a read-only
shared buffer, you can just throw away the contents, while a dirty
buffer requires you to write it into the kernel before you can use it.
--
I think it all depends on your working set. Having shared memory be
smaller than you working set causes pages to have to be copied in from
the kernel buffers (not a huge problem, but a small penalty), while
having shared memory larger than the working set causes overhead of
searching through all
Scott,
> Once someone is getting into the 8 way Itanium II with 32 Gigs of RAM,
> the fact that they are doing something that big means that by looking at
> the default, the workgroup, and the large server configs, they can
> extrapolate and experiment to determine the best settings, and are go
On Wed, 30 Jul 2003, Josh Berkus wrote:
> Ron,
>
> > I don't know if this is representative of other postgresql installs, but
> > I would also put in my vote for the differentiation added, as these are
> > not small machines but are multi-server boxes.
>
> But how is the Multi-purpose configur
Tom Lane wrote:
Rajesh Kumar Mallah <[EMAIL PROTECTED]> writes:
What lead to degradation was the bumping off of
effective_cache_size parameter from 1000 to 64K
Check the plan then; AFAIR the only possible effect of changing
effective_cache_size is to influence which plan the planner picks.
Ron,
> I don't know if this is representative of other postgresql installs, but
> I would also put in my vote for the differentiation added, as these are
> not small machines but are multi-server boxes.
But how is the Multi-purpose configuration different from the Small Machine
configuration?
Josh Berkus wrote:
Robert,
Are you planning on differentiating between dedicated machines and
multi-server
machines? For example, a dedicated database for a webserver would be tuned
differently from a server that was running both the webserver and the
database on
the same mac
Robert,
> Are you planning on differentiating between dedicated machines and
multi-server
> machines? For example, a dedicated database for a webserver would be tuned
> differently from a server that was running both the webserver and the
database on
> the same machine.
My thought is when we d
On Wed, 30 Jul 2003 10:59:23 -0600 (MDT), "scott.marlowe" wrote:
>
> I'm looking at doing the example postgresql.conf files for the 7.4
> release. So far, the catagories we have would be a matrix of:
>
> -- Large Machine -- Small Machine
> Webserver
> OLAP
> OLTP
> Workstation
>
> B
On Wed, 2003-07-30 at 11:59, scott.marlowe wrote:
> I'm looking at doing the example postgresql.conf files for the 7.4
> release. So far, the catagories we have would be a matrix of:
>
> -- Large Machine -- Small Machine
> Webserver
> OLAP
> OLTP
> Workstation
>
> But likely only one
Scott,
> I'm guessing OLTP needs things like FSM cranked up,
> OLAP (a for analytical) needs more shared buffers and sort memory
> Webserver might be better served just slightly higher values than default
> but well under those of either OLTP or OLAP...
Yes. Take sort_mem for example:
OLTP_SM 1
Mark,
I'm crossing this over to the performance list; it's really appropriate on
both lists. So I'm quoting you in full as well.
> I have a question regarding the performance of a function returning a
> set of a view as opposed to just selecting the view with the same
> where clause. Please
I'm looking at doing the example postgresql.conf files for the 7.4
release. So far, the catagories we have would be a matrix of:
-- Large Machine -- Small Machine
Webserver
OLAP
OLTP
Workstation
But likely only one entry for workstation.
anyone have any advice on what they use in wh
Folks,
Sorry for the cross-posting!
Somebody approached me with the skeleton of a "Gettting started with
PostgreSQL" page, and now I can't find the e-mail. Who was it? Please send
again!
--
Josh Berkus
Aglio Database Solutions
San Francisco
---(end of broadcast)---
On Tue, 2003-07-29 at 15:38, Ron Johnson wrote:
> On Tue, 2003-07-29 at 15:09, scott.marlowe wrote:
> > On 29 Jul 2003, Ron Johnson wrote:
> >
> > > On Tue, 2003-07-29 at 14:00, scott.marlowe wrote:
> > > > On 29 Jul 2003, Ron Johnson wrote:
> > > >
> > > > > On Tue, 2003-07-29 at 11:18, scott.ma
On 30 Jul 2003 at 12:54, Rajesh Kumar Mallah wrote:
> Can any one point me the recent guide done by
> Sridhar and Josh i want to see what i mis(read|understood)
> from there ;-) [ it was on GeneralBits' Home Page ]
http://www.varlena.com/GeneralBits/Tidbits/perf.html
HTH
Bye
Shridhar
--
pr
Rajesh Kumar Mallah <[EMAIL PROTECTED]> writes:
> What lead to degradation was the bumping off of
> effective_cache_size parameter from 1000 to 64K
Check the plan then; AFAIR the only possible effect of changing
effective_cache_size is to influence which plan the planner picks.
Dear Tom,
the problem was repeatble in the sense repeated
execution of queries made no difference on
performance.
What lead to degradation was the bumping off of
effective_cache_size parameter from 1000 to 64K
Can any one point me the recent guide done by
Sridhar and Josh i want to see wha
21 matches
Mail list logo
