Why couldn't Postgres learn for itself what the optimal performance
settings would be? The easy one seems to be the effective_cache_size.
Top shows us this information. Couldn't Postgres read that value from
the same place top reads it instead of relying on a config file value?
Seems like it
On Sun, 6 Jul 2003, Martin Foster wrote:
> The processor seems to be purposely sitting there twiddling it's thumbs.
> Which leads me to believe that perhaps the nice levels have to be
> changed on the server itself?
It could also be all the usual things that affect performance. Are your
quer
On Sat, Jul 05, 2003 at 02:12:56PM -0700, Sean Chittenden wrote:
> The SGML docs aren't in the DBA's face and are way out of the way for
> DBAs rolling out a new system or who are tuning the system. SGML ==
> Developer, conf == DBA.
I could not disagree more. I'd say more like, if the dba won't
> -Original Message-
> From: [EMAIL PROTECTED] [mailto:pgsql-performance-
> [EMAIL PROTECTED] On Behalf Of Andrew Sullivan
> Sent: Monday, July 07, 2003 5:23 AM
> To: [EMAIL PROTECTED]
> Subject: Re: [PERFORM] Moving postgresql.conf tunables into 2003...
>
> On Sat, Jul 05, 2003 at 02:12:
> Are you willing to say that the PostgreSQL database system should only be
> used by DBAs? I believe that Postgres is such a good and useful tool that
> anyone should be able to start using it with little or no barrier
> to entry.
This is a good point. After reading previous responses I was sta
"Matthew Nuzum" <[EMAIL PROTECTED]> writes:
> Are you willing to say that the PostgreSQL database system should only be
> used by DBAs? I believe that Postgres is such a good and useful tool that
> anyone should be able to start using it with little or no barrier to entry.
I quite agree. But the
Our production database is running under 7.2.4; our test database
running almost the same data is at 7.3.3. One table has about 400,000
rows in each schema. A query against an indexed column uses an index
scan under 7.2.4, but a sequential scan under 7.3.3. A count of the
table in question shows t
On Monday 07 Jul 2003 3:17 pm, Jeff Boes wrote:
> Our production database is running under 7.2.4; our test database
> running almost the same data is at 7.3.3. One table has about 400,000
> rows in each schema. A query against an indexed column uses an index
> scan under 7.2.4, but a sequential sc
Someone asked a hypothetical question about how to retrieve all records of a
table twice in SQL. It got me thinking about whether there was a way to do
this efficiently.
"Obviously" if you do it using the UNION ALL approach postgres isn't going to
do two separate scans, doing it otherwise would b
On Sun, 6 Jul 2003, Martin Foster wrote:
> Shridhar Daithankar wrote:
> >
> > It gives hint to psotgresql how much file system cache is available in the
> > system.
> >
> > You have 1GB memory and your application requirement does not exceed 400MB. So
> > OS can use roughly 600MB for file sys
On Mon, 7 Jul 2003, Brian Tarbox wrote:
> Oddly enough, the particular application in question will have an extremely
> small user base...perhaps a few simultainous users at most.
>
> As to the testing, I neglected to say early in this thread that my manager
> instructed me _not_ to do further pe
On Monday 07 July 2003 12:22 pm, you wrote:
> loops=1) -> Seq Scan on region (cost=0.00..2813.00 rows=2767 width=104)
> (actual time=0.03..123.44 rows=2767 loops=2) Total runtime: 566.24 msec
> (9 rows)
>
> (I'm also a bit puzzled why the optimizer is calculating that 2,813 * 2 =
> 5,534)
You s
On Fri, 4 Jul 2003, Brian Tarbox wrote:
> I'm actually leaving this list but I can answer this question. Our results
> were with a single user and we were running Inodb. We were running on
> RedHat 8.0 / 9.0 with vanilla linux settings.
Hi Brian, I just wanted to add that if you aren't testing
Matthew Nuzum wrote:
I'm highly resistant to/disappointed in this attitude and firmly
believe that there are well understood algorithms that DBAs use to
diagnose and solve performance problems. It's only a black art
because it hasn't been documented. Performance tuning isn't voodoo,
it's adjusti
I'm willing to help too. I'm basically a DBA / developer type, with mild
C hacking skills (I develop in PHP, so my C coding is quite rusty
nowadays.)
If nothing else testing on different equipment / OSes.
On Fri, 4 Jul 2003, Josh Berkus wrote:
> Kaarel:
>
> (cross-posted back to Performance
Oddly enough, the particular application in question will have an extremely
small user base...perhaps a few simultainous users at most.
As to the testing, I neglected to say early in this thread that my manager
instructed me _not_ to do further performance testing...so as a good
consultant I compl
On Mon, Jul 07, 2003 at 10:08:50AM -0700, Chris Travers wrote:
> In my opinion, a serious RDBMS system will *always* require the admin to
> be doing research in order to learn how to use it effectively. We are
> not talking about a word processor here.
>
> That being said, I think that a good p
scott.marlowe wrote:
I would try a few things. First off, effective_cache_size is the size
measured in 8k blocks, so 512 would be a setting of 4 Megs. Probably a
little low. If you average 512Meg free, that would be a setting of 65536.
Note that the higer the effective_cache_size, the more
> A common problem is a table like this:
>
> create table test (info text, id int8 primary key);
> insert into test values ('ted',1);
> .. a few thousand more inserts;
> vacuum full;
> analyze;
> select * from test where id=1;
>
> will result in a seq scan, always, because the 1 by itself is
> au
19 matches
Mail list logo
