On Fri, 27 Apr 2007, Josh Berkus wrote:
Dan,
Yes, this is the classic problem. I'm not demanding anyone pick up the
ball and jump on this today, tomorrow, etc.. I just think it would be
good for those who *could* make a difference to keep those goals in mind
when they continue. If you have t
Dan,
> Yes, this is the classic problem. I'm not demanding anyone pick up the
> ball and jump on this today, tomorrow, etc.. I just think it would be
> good for those who *could* make a difference to keep those goals in mind
> when they continue. If you have the right mindset, this problem will
"Mauro N. Infantino" <[EMAIL PROTECTED]> writes:
> What we basically have is a site where each user has a box with links to
> other randomly selected users. Whenever a box from a user is shown, a SPs is
> executed: a credit is added to that user and a credit is substracted from
> the accounts of th
Bill Moran wrote:
In response to Dan Harris <[EMAIL PROTECTED]>:
Why does the user need to manually track max_fsm_pages and max_fsm_relations? I
bet there are many users who have never taken the time to understand what this
means and wondering why performance still stinks after vacuuming the
Bill,
> The only one that seems practical (to me) is random_page_cost. The
> others are all configuration options that I (as a DBA) want to be able
> to decide for myself.
Actually, random_page_cost *should* be a constant "4.0" or "3.5", which
represents the approximate ratio of seek/scan spee
On Fri, Apr 27, 2007 at 02:40:07PM -0400, Kevin Hunter wrote:
> out that many run multiple postmasters or have other uses for the
> machines in question), but perhaps it could send a message (email?)
> along the lines of "Hey, I'm currently doing this many of X
> transactions, against this mu
At 10:36a -0400 on 27 Apr 2007, Tom Lane wrote:
That's been proposed and rejected before, too; the main problem being
that initdb is frequently a layer or two down from the user (eg,
executed by initscripts that can't pass extra arguments through, even
assuming they're being invoked by hand in th
In response to Dan Harris <[EMAIL PROTECTED]>:
> Michael Stone wrote:
> > On Fri, Apr 27, 2007 at 09:27:49AM -0400, Carlos Moreno wrote:
> >> Notice that the second part of my suggestion covers this --- have
> >> additional
> >> switches to initdb
>
> > If the person knows all that, why wouldn't
Dan,
> Exactly.. What I think would be much more productive is to use the
> great amount of information that PG tracks internally and auto-tune the
> parameters based on it. For instance:
*Everyone* wants this. The problem is that it's very hard code to write
given the number of variables. I
Michael Stone wrote:
On Fri, Apr 27, 2007 at 09:27:49AM -0400, Carlos Moreno wrote:
Notice that the second part of my suggestion covers this --- have
additional
switches to initdb
If the person knows all that, why wouldn't they know to just change the
config parameters?
Exactly.. What I
Hi,
We're facing some perfomance problems with the database for a web site with
very specific needs. First of all, we're using version 8.1 in a server with
1GB of RAM. I know memory normally should be more, but as our tables are not
so big (as a matter of fact, they are small) I think the solution
"Siddharth Anand" <[EMAIL PROTECTED]> writes:
> My question wasn't phrased clearly. Oracle exhibits a performance
> degradation for very large-sized fields (CLOB types that I equate to
> PostGres' text type) when compared with the performance of field types
> like varchar that handle a max characte
Hi Tom,
My question wasn't phrased clearly. Oracle exhibits a performance
degradation for very large-sized fields (CLOB types that I equate to
PostGres' text type) when compared with the performance of field types
like varchar that handle a max character limit of a few thousand bytes in
Oracle.
It
I think the manual is implying that if you store a value like "Sid" in a
field either of type varchar(128) or type text there is no performance
difference. The manual is not saying that you get the same performance
storing a 500k text field as when you store the value "Sid".
Dave
-Original
Siddharth Anand wrote:
Hi!
I read the link below and am puzzled by or curious about something.
http://www.postgresql.org/docs/8.1/interactive/datatype-character.html
The Tip below is intriguing
"Tip: There are no performance differences between these three types,
apart from the increased stora
"Siddharth Anand" <[EMAIL PROTECTED]> writes:
> How can a field that doesn't have a limit like "text" perform similarly to
> char varying(128), for example? At some point, we need to write data to
> disk. The more data that needs to be written, the longer the disk write
> will take, especially when
On Apr 27, 2007, at 3:30 PM, Michael Stone wrote:
On Fri, Apr 27, 2007 at 09:27:49AM -0400, Carlos Moreno wrote:
Notice that the second part of my suggestion covers this --- have
additional
switches to initdb so that the user can tell it about estimates on
how the DB
will be used: estimated
Hi!
I read the link below and am puzzled by or curious about something.
http://www.postgresql.org/docs/8.1/interactive/datatype-character.html
The Tip below is intriguing
"Tip: There are no performance differences between these three types,
apart from the increased storage size when using the bl
Hi!
I read the link below and am puzzled by or curious about something.
http://www.postgresql.org/docs/8.1/interactive/datatype-character.html
The Tip below is intriguing
"Tip: There are no performance differences between these three types,
apart from the increased storage size when using the bl
On Fri, Apr 27, 2007 at 07:36:52AM -0700, Mark Lewis wrote:
Maybe he's looking for a switch for initdb that would make it
interactive and quiz you about your expected usage-- sort of a magic
auto-configurator wizard doohicky? I could see that sort of thing being
nice for the casual user or newbi
Hello.
Just my 2 cents, and not looking to the technical aspects:
setting up PSQL is the weakest point of PSQL as we have experienced ourself,
once it is running it is great.
I can imagine that a lot of people of stops after their first trials after
they have
experienced the troubles and perfo
Maybe he's looking for a switch for initdb that would make it
interactive and quiz you about your expected usage-- sort of a magic
auto-configurator wizard doohicky? I could see that sort of thing being
nice for the casual user or newbie who otherwise would have a horribly
mis-tuned database. The
Carlos Moreno <[EMAIL PROTECTED]> writes:
> Tom Lane wrote:
>> But
>> the fundamental problem remains that we don't know that much about
>> how the installation will be used.
> Notice that the second part of my suggestion covers this --- have
> additional switches to initdb
That's been proposed
On Fri, Apr 27, 2007 at 09:27:49AM -0400, Carlos Moreno wrote:
Notice that the second part of my suggestion covers this --- have
additional
switches to initdb so that the user can tell it about estimates on how
the DB
will be used: estimated size of the DB, estimated percentage of
activity tha
Adding -performance back in so others can learn.
On Apr 26, 2007, at 9:40 AM, Paweł Gruszczyński wrote:
Jim Nasby napisał(a):
On Apr 25, 2007, at 8:51 AM, Paweł Gruszczyński wrote:
where u6 stores Fedora Core 6 operating system, and u0 stores 3
partitions with ext2, ext3 and jfs filesystem.
Tom Lane wrote:
Carlos Moreno <[EMAIL PROTECTED]> writes:
... But, wouldn't it make sense that the configure script
determines the amount of physical memory and perhaps even do a HD
speed estimate to set up defaults that are closer to a
performance-optimized
configuration?
No. Most
On Fri, Apr 27, 2007 at 07:23:41PM +0930, Shane Ambler wrote:
I would think that as you are sitting and watching the cpu usage, your
query would seem to taking a while to run, leading me to wonder if you
are getting a full table scan that is causing pg to wait for disk response?
If so, you pro
Magnus Hagander wrote:
On Fri, Apr 27, 2007 at 08:10:48AM +, Andres Retzlaff wrote:
Hi Magnus,
in this case each CPU goes up to 50%, giveing me 50% total usage. I was
specting as you say 1 query 100% cpu.
Any ideas?
No. 1 query will only use 100% of *one* CPU, which means 50% total usa
On Fri, Apr 27, 2007 at 08:10:48AM +, Andres Retzlaff wrote:
> Hi Magnus,
>
> in this case each CPU goes up to 50%, giveing me 50% total usage. I was
> specting as you say 1 query 100% cpu.
>
> Any ideas?
No. 1 query will only use 100% of *one* CPU, which means 50% total usage.
You need at
Hi Magnus,
in this case each CPU goes up to 50%, giveing me 50% total usage. I was
specting as you say 1 query 100% cpu.
Any ideas?
Andrew
On Fri, Apr 27, 2007 at 04:43:06AM +, Andres Retzlaff wrote:
> Hi,
>
> I have pg 8.1.4 running in
> Windows XP Pro
> wirh a Pentium D
>
> and I notic
On Fri, Apr 27, 2007 at 04:43:06AM +, Andres Retzlaff wrote:
> Hi,
>
> I have pg 8.1.4 running in
> Windows XP Pro
> wirh a Pentium D
>
> and I notice that I can not use more than 50% of the cpus (Pentium D has 2
> cpus), how can I change the settings to use the 100% of it.
A single query w
* Bill Moran:
> To clarify my viewpoint:
> To my knowledge, there is no Unix filesystem that _suffers_ from
> fragmentation. Specifically, all filessytems have some degree of
> fragmentation that occurs, but every Unix filesystem that I am aware of
> has built-in mechanisms to mitigate this and p
32 matches
Mail list logo
