On 2/23/07, Geoffrey <esoteric@3times25.net> wrote:
> As I've heard. We're headed for 8 as soon as possible, but until we get
> our code ready, we're on 7.4.16.

You should move to at least 8.1 and possibly 8.2. It's not a good idea
to upgrade only to 8 IMHO.

--
Guillaume

---------------------------(end of broadcast)---------------------------
TIP 6: explain analyze is your friend

Alvaro Herrera wrote:
> Steinar H. Gunderson wrote:
>> On Fri, Feb 23, 2007 at 02:05:57PM -0500, Geoffrey wrote:
>>> In searching the archives, I can't find any specific info indentifying
>>> which Xeon processors don't have this problem.
>> AFAIK the cut-off point is at the Woodcrests. They are overall much better
>> suited to PostgreSQL than the older Xeons were.
>>
>> It's slightly unfortunate that AMD and Intel cling to the Opteron and Xeon
>> names even though they're making significant architecture changes, but that's
>> life, I guess.
>
> AFAIR Intel has been calling their server processors Xeon since Pentium
> Pro's, at least.
>
Almost. Xeon was the new name for the "Pro" series. Instead of Pentium
II Pro, we got Pentium II Xeon. The whole Pentium Pro line was a server
line, which is why initial Pentium-II CPUs were significantly slower for
server apps than the much older ppro (which still runs pg at a
reasonable speed if you have enough of them and a low budget, btw)

//Magnus

---------------------------(end of broadcast)---------------------------
TIP 7: You can help support the PostgreSQL project by donating at

http://www.postgresql.org/about/donate

Guillaume Smet wrote:
> On 2/23/07, Geoffrey <esoteric@3times25.net> wrote:
>> As I've heard. We're headed for 8 as soon as possible, but until we get
>> our code ready, we're on 7.4.16.
>
> You should move to at least 8.1 and possibly 8.2. It's not a good idea
> to upgrade only to 8 IMHO.

When I said 8, I meant whatever the latest greatest 8 is. Right now,
that looks like 8.2.3.

--
Until later, Geoffrey

Those who would give up essential Liberty, to purchase a little
temporary Safety, deserve neither Liberty nor Safety.
- Benjamin Franklin

---------------------------(end of broadcast)---------------------------
TIP 9: In versions below 8.0, the planner will ignore your desire to
choose an index scan if your joining column's datatypes do not
match

Geoffrey wrote:
> Guillaume Smet wrote:
>> On 2/23/07, Geoffrey <esoteric@3times25.net> wrote:
>>> As I've heard. We're headed for 8 as soon as possible, but until we get
>>> our code ready, we're on 7.4.16.
>>
>> You should move to at least 8.1 and possibly 8.2. It's not a good idea
>> to upgrade only to 8 IMHO.
>
> When I said 8, I meant whatever the latest greatest 8 is. Right now,
> that looks like 8.2.3.

No. The latest version of 8.2 is 8.2.3, there is also 8.1 which is at
8.1.8 and 8.0 which is at 8.0.12.

They are all different *major* releases.

IMO, nobody should be running anything less than 8.1.8.

Sincerely,

Joshua D. Drake


--

=== The PostgreSQL Company: Command Prompt, Inc. ===
Sales/Support: +1.503.667.4564 || 24x7/Emergency: +1.800.492.2240
Providing the most comprehensive PostgreSQL solutions since 1997
http://www.commandprompt.com/

Donate to the PostgreSQL Project: http://www.postgresql.org/about/donate
PostgreSQL Replication: http://www.commandprompt.com/products/


---------------------------(end of broadcast)---------------------------
TIP 1: if posting/reading through Usenet, please send an appropriate
subscribe-nomail command to majordomo@postgresql.org so that your
message can get through to the mailing list cleanly

Say that I have a dual-core processor (AMD64), with, say, 2GB of memory
to run PostgreSQL 8.2.3 on Fedora Core X.

I have the option to put two hard disks (SATA2, most likely); I'm
wondering
what would be the optimal configuration from the point of view of
performance.

I do have the option to configure it in RAID-0, but I'm sort of
reluctant; I think
there's the possibility that having two filesystems that can be accessed
truly
simultaneously can be more beneficial. The question is: does PostgreSQL
have separate, independent areas that require storage such that performance
would be noticeably boosted if the multiple storage operations could be
done
simultaneously?

Notice that even with RAID-0, the "twice the performance" may turn into
an illusion --- if the system requires access from "distant" areas of
the disk
("distant" as in many tracks apart), then the back-and-forth travelling of
the heads would take precedence over the doubled access speed ... Though
maybe it depends on whether accesses are in small chunks (in which case
the cache of the hard disks could take precedence).

Coming back to the option of two independent disks --- the thing is: if it
turns out that two independent disks are a better option, how should I
configure the system and the mount points? And how would I configure
PostgreSQL to take advantage of that?

Advice, anyone?

Thanks,

Carlos
--


---------------------------(end of broadcast)---------------------------
TIP 2: Don't 'kill -9' the postmaster

Carlos Moreno <moreno_pg@mochima.com> writes:
> The question is: does PostgreSQL have separate, independent areas that
> require storage such that performance would be noticeably boosted if
> the multiple storage operations could be done simultaneously?

The standard advice in this area is to put pg_xlog on a separate
spindle; although that probably is only important for update-intensive
applications. You did not tell us anything about your application...

regards, tom lane

---------------------------(end of broadcast)---------------------------
TIP 7: You can help support the PostgreSQL project by donating at

http://www.postgresql.org/about/donate

On Feb 25, 2007, at 04:39 , Carlos Moreno wrote:

> I do have the option to configure it in RAID-0, but I'm sort of
> reluctant; I think
> there's the possibility that having two filesystems that can be
> accessed truly
> simultaneously can be more beneficial. The question is: does
> PostgreSQL
> have separate, independent areas that require storage such that
> performance
> would be noticeably boosted if the multiple storage operations
> could be done
> simultaneously?

Putting the WAL (aka pg_xlog) on a separate disk will take some load
off your main database disk. See http://www.varlena.com/GeneralBits/
Tidbits/perf.html for this.

It is also possible to put individual tables and/or indexes on
separate disks by using tablespaces: "For example, an index which is
very heavily used can be placed on a very fast, highly available
disk, such as an expensive solid state device. At the same time a
table storing archived data which is rarely used or not performance
critical could be stored on a less expensive, slower disk
system." (http://www.postgresql.org/docs/8.2/i...ive/manage-ag-
tablespaces.html)

In both cases, the performance benefits tend to be relative to the
amount of write activity you experience, and the latter solution
assumes you know where the hotspots are. If you have two tables that
see continuous, intense write activity, for example, putting each on
a separate disk

Alexander.

---------------------------(end of broadcast)---------------------------
TIP 3: Have you checked our extensive FAQ?

http://www.postgresql.org/docs/faq

A related question:
Is it sufficient to disable write cache only on the disk where pg_xlog
is located? Or should write cache be disabled on both disks?

Thanks
Peter

On 2/25/07, Tom Lane <tgl@sss.pgh.pa.us> wrote:
> Carlos Moreno <moreno_pg@mochima.com> writes:
> > The question is: does PostgreSQL have separate, independent areas that
> > require storage such that performance would be noticeably boosted if
> > the multiple storage operations could be done simultaneously?
>
> The standard advice in this area is to put pg_xlog on a separate
> spindle; although that probably is only important for update-intensive
> applications. You did not tell us anything about your application...
>
> regards, tom lane
>
> ---------------------------(end of broadcast)---------------------------
> TIP 7: You can help support the PostgreSQL project by donating at
>
> http://www.postgresql.org/about/donate
>

---------------------------(end of broadcast)---------------------------
TIP 6: explain analyze is your friend

On Sun, 2007-02-25 at 23:11 +0100, Peter Kovacs wrote:
> A related question:
> Is it sufficient to disable write cache only on the disk where pg_xlog
> is located? Or should write cache be disabled on both disks?
>

When PostgreSQL does a checkpoint, it thinks the data pages before the
checkpoint have successfully made it to disk.

If the write cache holds those data pages, and then loses them, there's
no way for PostgreSQL to recover. So use a battery backed cache or turn
off the write cache.

Regards,
Jeff Davis


---------------------------(end of broadcast)---------------------------
TIP 9: In versions below 8.0, the planner will ignore your desire to
choose an index scan if your joining column's datatypes do not
match

On 2/26/07, Jeff Davis <pgsql@j-davis.com> wrote:
> On Sun, 2007-02-25 at 23:11 +0100, Peter Kovacs wrote:
> > A related question:
> > Is it sufficient to disable write cache only on the disk where pg_xlog
> > is located? Or should write cache be disabled on both disks?
> >
>
> When PostgreSQL does a checkpoint, it thinks the data pages before the
> checkpoint have successfully made it to disk.
>
> If the write cache holds those data pages, and then loses them, there's
> no way for PostgreSQL to recover. So use a battery backed cache or turn
> off the write cache.

Sorry for for not being familar with storage techonologies... Does
"battery" here mean battery in the common sense of the word - some
kind of independent power supply? Shouldn't the disk itself be backed
by a battery? As should the entire storage subsystem?

Thanks
Peter

>
> Regards,
> Jeff Davis
>
>

---------------------------(end of broadcast)---------------------------
TIP 7: You can help support the PostgreSQL project by donating at

http://www.postgresql.org/about/donate