Re: [PERFORM] Moving postgresql.conf tunables into 2003...

2003-07-03 Thread Ron
people to use it. Ron St.Pierre BTW I'm looking forward to Josh's configuration doc. Sean Chittenden wrote: What are the odds of going through and revamping some of the tunables in postgresql.conf for the 7.4 release? I was just working with someone on IRC and on their 7

Re: [PERFORM] postgresql.conf

2003-07-30 Thread Ron
re multi-server boxes. my 2 cents worth Ron PS the new postgresql.conf performance tuning docs are extremely helpful, thanks ---(end of broadcast)--- TIP 8: explain analyze is your friend

[OT] Such incredible h/w (was Re: [PERFORM] Dual Xeon + HW RAIDquestion)

2003-07-12 Thread Ron Johnson
eople that recomends a Software RAID instead HW. > > > > I think too remove the RAID 5 and turn a RAID 1 for > > data in 2 HDs. > > SO, WAL and swap in the thrid HD. > > > > My questions: > > > > 1) I will see best disk performance changing the disk

Re: [PERFORM] Hardware performance

2003-07-18 Thread Ron Johnson
ts are deep enough, you can make everything redundant and burden-sharing (i.e., not just waiting for the master system to die). (And with some enterprise FC controllers, you can mirror the disks many kilometers away.) -- +-----+ | Ron Johns

Re: [PERFORM] Hardware performance

2003-07-18 Thread Ron Johnson
t forget to check the batteries!!! And if you have an HPaq service contract, don't rely on them to do it... -- +-+ | Ron Johnso

Re: [PERFORM] Tuning PostgreSQL

2003-07-22 Thread Ron Johnson
". http://www.linuxworld.com/story/32673.htm -- +-----+ | Ron Johnson, Jr.Home: [EMAIL PROTECTED] | | Jefferson, LA USA | | | | &q

Re: [PERFORM] Tuning PostgreSQL

2003-07-22 Thread Ron Johnson
for a long, painful boot process if the box crashes. (For example, the UPS auto-shutdown daemon doesn't work properly, and no one can get to the console to shut it down properly before the batteries die.) -- +------

Re: [PERFORM] Tuning PostgreSQL

2003-07-22 Thread Ron Johnson
em to another machine, and the data should be just as it was on the other box. -- +-+ | Ron Johnson, Jr.Home: [EMAIL PROTECTED] | | Jefferson, LA USA | | | | "I'm no

Re: [PERFORM] hardware performance and some more

2003-07-24 Thread Ron Johnson
;t available. How complicated are each of these SELECT statements? -- +-----+ | Ron Johnson, Jr.Home: [EMAIL PROTECTED] | | Jefferson, LA USA | |

Re: [PERFORM] Tuning PostgreSQL

2003-07-24 Thread Ron Johnson
an 128M. I think > it had 1G and could be expanded. Your last paragraph just stole the objection to the 1st paragraph right out of my mouth, since enough cache will allow it to "batch" all those tiny updates into big updates. But those Hitachi controllers weren&#x

Re: [PERFORM] hardware performance and some more

2003-07-25 Thread Ron Johnson
et away with less expensive machines, say 2GHz CPU, 1GB RAM and a 40GB IDE drive. Then, if one goes down for some reason, you've only lost a small portion of your capacity, and replacing a part will be very inexpensive. And if volume increases, just add more USD1000 machines... -- +---

Re: [PERFORM] hardware performance and some more

2003-07-25 Thread Ron Johnson
x27;s using it. Wouldn't the cache on the read-only databases get out of sync with the true on-disk data? -- +-+ | Ron Johnson, Jr.Home: [EMAIL PROTECTED] | | Jefferson, LA USA

Re: [PERFORM] index questions

2003-07-25 Thread Ron Johnson
months? When faced with cases like this, I cobble together a script/program that generates a few million rows of random data (within the confines of FKs, of course) to populate these tables like "sales", and then I see how things perform. -- +-------

Re: [PERFORM] Tuning PostgreSQL

2003-07-29 Thread Ron Johnson
. If your app needs One Big Honkin' Device, use the Linux Volume Manager (LVM) to merge the 2 RAID logical devices into one "super- logical" device. Yes, that's lot's of money, but is the data, and spe

Re: [PERFORM] Tuning PostgreSQL

2003-07-29 Thread Ron Johnson
On Tue, 2003-07-29 at 11:18, scott.marlowe wrote: > On 29 Jul 2003, Ron Johnson wrote: > > > On Tue, 2003-07-29 at 10:14, Vivek Khera wrote: > > > >>>>> "GS" == Greg Stark <[EMAIL PROTECTED]> writes: > > > > > > GS> &qu

Re: [PERFORM] Tuning PostgreSQL

2003-07-29 Thread Ron Johnson
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.marlowe wrote: > > > On 29 Jul 2003, Ron Johnson wrote: > > > > > > > On Tue, 2003-07-29 at 10:14, Vivek Khera wrote:

Re: [PERFORM] Tuning PostgreSQL

2003-07-29 Thread Ron Johnson
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.marlowe wrote: &

Re: [PERFORM] Tuning PostgreSQL, pt 2

2003-07-30 Thread Ron Johnson
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: > >

Re: [PERFORM] postgresql.conf

2003-07-30 Thread Ron Johnson
ng 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... -- +---

[PERFORM] Targeted CPU compilations

2003-07-30 Thread Ron Johnson
. -- +-+ | Ron Johnson, Jr.Home: [EMAIL PROTECTED] | | Jefferson, LA USA | | | | "I'm not a vegetarian because I love animals, I'm a vegetarian | |

Re: [PERFORM] EXTERNAL storage and substring on long strings

2003-07-31 Thread Ron Johnson
s enough to > swamp the time saved from not needing to uncompress. Are you asking, "Can his CPU decompress faster than his disks can read?" -- +--

Re: [PERFORM] How number of columns affects performance

2003-08-01 Thread Ron Johnson
ou can get off all lists at once with the unregister command > (send "unregister YourEmailAddressHere" to [EMAIL PROTECTED]) -- +-+ | Ron Johnson, Jr.Home: [EMAIL PROTECTED] | | Jefferson, LA USA

Re: [PERFORM] How number of columns affects performance

2003-08-01 Thread Ron Johnson
On Fri, 2003-08-01 at 12:14, Francisco J Reyes wrote: > On Fri, 1 Aug 2003, Ron Johnson wrote: > > > Do all 100 fields *really* all refer to the same *one* entity, > > with no repeating values, etc? > > Yes all fields belong to the same entity. I used 100 as an example it

Re: [PERFORM] How number of columns affects performance

2003-08-01 Thread Ron Johnson
then* take denormalization steps to improve it. The OP was not talking about denormalizing ... It was: will vertically partitioning a table increase performance. And the answer is "sometimes", -- +

[PERFORM] testing

2003-08-03 Thread Ron Johnson
-- +-+ | Ron Johnson, Jr.Home: [EMAIL PROTECTED] | | Jefferson, LA USA | | | | "I'm not a

Re: [PERFORM] PostgreSQL performance problem -> tuning

2003-08-07 Thread Ron Johnson
y, "Give me all the RAM; I will cache everything myself." PostgreSQL says "The kernel programmers have worked very hard on disk caching. Why should I duplicate their efforts?" Thus, give PG only a "little" RAM, and let the OS' disk cache h

Re: [PERFORM] Perfomance Tuning

2003-08-12 Thread Ron Johnson
ure > > until it's been through a major version (e.g. things introduced in > > 2.4.x won't really be stable until 2.6.x) -- and even there one is > > taking a risk[1]. > > Dudes, seriously - switch to FreeBSD :P But, like, we want a *good* OS... 8-0 -- +---

Re: [PERFORM] Odd problem with performance in duplicate database

2003-08-12 Thread Ron Johnson
ould one identical database pick a different plan than its copy? If the databases are on different machines, maybe the postgres.conf or pg_hba.conf files are different, and the buffer counts is affect- ing the optimizer? -- +---+

Re: [PERFORM] Perfomance Tuning

2003-08-14 Thread Ron Johnson
ave way more net throughput than a single RAID > array on scsi. I wouldn't be surprised either if the fiber array had more cache than the SCSI controller. Was/is the Hitachi device a SAN? -- +---

Re: [PERFORM] Perfomance Tuning

2003-08-14 Thread Ron Johnson
> > data=writeback, rather than the default of data=ordered. > > > > BTW, I've heard from a couple different people that using > > ext3 with data=journalled (i.e. enabling journalling of both > > data

Re: [PERFORM] Perfomance Tuning

2003-08-14 Thread Ron Johnson
d FS technology since Informix > was designed. Wouldn't PG 1st need horizontal partitioning, and as a precursor to that, "tablespaces"? -- +---+ | Ron J

Re: [PERFORM] Perfomance Tuning

2003-08-14 Thread Ron Johnson
1,920 inserts/second. for f in ltx_*unl.gz; do psql test1 -c "truncate table t_lane_tx2;" ; (zcat $f | sed "s/\"//g" | \ psql test1 -c "copy t_lane_tx2 from stdin delimiter ',';"); time psql -a -f sel_into_ltx.sql -d test1 ; done

Re: [PERFORM] Hardware recommendations to scale to silly load

2003-08-28 Thread Ron Johnson
. Rdb *does* have ways, though, using large buffers and hashed indexes, with the table tuples stored on the same page as the hashed index keys, to make such accesses *blazingly* fast. > Many thanks for reading this far. -- - Ron Johnson, Jr. [EMAIL PROTECTED] Jefferson, LA USA

Re: [PERFORM] Hardware recommendations to scale to silly load

2003-08-28 Thread Ron Johnson
solidation", and VMware does the same thing, 30 years after dinosaur customers had it on boxen that academics, analysts and "young whippersnappers" said were supposed to be extinct 20 years ago. -- ----- Ron Johnson, Jr.

Re: [PERFORM] Hardware recommendations to scale to silly load

2003-08-28 Thread Ron Johnson
high-volume apps solved The Need For Speed. With VMS 7.3 and Rdb 7.1.04 and, oh, 16GB RAM, a carefully crafted stored procedure run an hour or 2 before the show could pull the necessary 5GB slice of the DB into GBs, and you'd reduce the I/O load during the show itself. Sorry it's not P

Re: [PERFORM] The results of my PostgreSQL/filesystem performance

2003-08-28 Thread Ron Johnson
to see how Debian Sid (kernel 2.4.21 and pg 7.3.3) would perform. Thanks for the results! -- ----- Ron Johnson, Jr. [EMAIL PROTECTED] Jefferson, LA USA "Oh, great altar of passive entertainment, bestow upon me thy discordant im

Re: [PERFORM] The results of my PostgreSQL/filesystem performance

2003-08-28 Thread Ron Johnson
weren't tested with noatime. Any reason? -- ----- Ron Johnson, Jr. [EMAIL PROTECTED] Jefferson, LA USA "As I like to joke, I may have invented it, but Microsoft made it popular" David Bradley, regarding Ctrl-Alt-Del ---(end of broadcast)---

Re: [PERFORM] Hardware recommendations to scale to silly load

2003-08-29 Thread Ron Johnson
even more towards AMD's favor. > > I am sure. But is 64 bit environment, Xeon is not the compitition. It's PA-RSC- > 8700, ultraSparcs, Power series and if possible itanium. IMO, Opti will compete in *both* markets. -- ---

Re: [PERFORM] Hardware recommendations to scale to silly load

2003-08-29 Thread Ron Johnson
What's so special about Itanic-2 that it can be engineered to be put in 128x boxes and run VMS and high-end Unix , but Opti can't? Nothing. If a company with enough engineering talent wants to do it, it can happen. -- - Ron

Re: [PERFORM] Hardware recommendations to scale to silly load

2003-08-30 Thread Ron Johnson
RAID10, I wouldn't be surprised if 4 con- current connections gives the optimum speed. -- - Ron Johnson, Jr. [EMAIL PROTECTED] Jefferson, LA USA Great Inventors of our time: Al Gore -> Internet

Re: [PERFORM] Selecting random rows efficiently

2003-08-30 Thread Ron Johnson
all the primary keys from my table, and > select one of the keys at random then directly fetch that row. > > are there any other ways to do this? i need to keep the load down :) > > Thanks, > Richard Are you really in Micronesia? -- ------

Re: [PERFORM] Selecting random rows efficiently

2003-08-30 Thread Ron Johnson
les, they'd all have to be updated, too. -- ----- Ron Johnson, Jr. [EMAIL PROTECTED] Jefferson, LA USA "Whatever may be the moral ambiguities of the so-called demoratic nations and however serious may be their failure to conform perfectly to their democratic ideals, it is sheer mor

Re: [PERFORM] How to force Nested Loop plan?

2003-08-30 Thread Ron Johnson
Scalars are faster than arbitrary precision types. Small (32 bit) scalars are faster than bit (64 bit) scalars on x86 h/w. -- ----- Ron Johnson, Jr. [EMAIL PROTECTED] Jefferson, LA USA "Adventure is a sign

Re: [PERFORM] How to force Nested Loop plan?

2003-08-30 Thread Ron Johnson
t tried it and it worked. This is the first query > where we ran out of ideas to try. Dumb question: given your out-of-the-box satisfaction, could it be that postgresql.conf hasn't been tweaked? -- ----- Ron Johnson, Jr. [EMAIL PRO

Re: [PERFORM] How to force Nested Loop plan?

2003-09-01 Thread Ron Johnson
given WHERE predicate resolves to. -- ----- Ron Johnson, Jr. [EMAIL PROTECTED] Jefferson, LA USA "Fair is where you take your cows to be judged." Unknown ---(end of broadcast)--- TIP 6: Have you sear

Re: [PERFORM] opinion on RAID choice

2003-09-02 Thread Ron Johnson
r. As near as I can > tell, you do _not_ want to use RAID 5 with Veritas. Why should Veritas care? Or is it that Veritas has a high overhead of small block writes? -- ----- Ron Johnson, Jr. [EMAIL PROTECTED] Jefferson, LA USA &quo

Re: [PERFORM] opinion on RAID choice

2003-09-02 Thread Ron Johnson
On Tue, 2003-09-02 at 11:47, Greg Spiegelberg wrote: > Ron Johnson wrote: > > On Tue, 2003-09-02 at 11:14, Andrew Sullivan wrote: > > > >>On Thu, Aug 28, 2003 at 03:26:14PM -0600, scott.marlowe wrote: > >> > >>>My experience has been that once you

Re: [PERFORM] Hardware recommendations to scale to silly load

2003-09-02 Thread Ron Johnson
pteron is supposed to have screaming fast inter-CPU memory xfer (HyperTransport does inter-CPU as well as well as CPU-RAM transport). That's supposed to help with scaling, and PostgreSQL really may take advantage of that, with, say 16-32 processors? -- -

Re: [PERFORM] SQL slower when running for the second time

2003-09-03 Thread Ron Johnson
kes more than 2 minutes, and > I should retunr faster than the first time. > > Does anyone have a advice ? Is it a query or insert/update? -- ----- Ron Johnson, Jr. [EMAIL PROTECTED] Jefferson, LA USA "Vanity, my favorit

Re: [PERFORM] [GENERAL] Seq scan of table?

2003-09-05 Thread Ron Johnson
if I'm wrong, but I believe numbers are int4's, so they > need to be cast if your column is not an int4. You mean "constant" scalars? Yes, constants scalars are interpreted as int4. -- - Ron Johnson, Jr. [E

Re: [PERFORM] advice on raid controller

2003-09-27 Thread Ron Johnson
ID 5 needs a *minimum* of 128MB cache to have good performance. -- ----- Ron Johnson, Jr. [EMAIL PROTECTED] Jefferson, LA USA Why is cyber-crime not being effectively controlled? What is fuelling the rampancy? * Parental apathy & the public education system h

[PERFORM] basket, eggs & NAS (was eggs Re: [NOVICE] Ideal Hardware?)

2003-10-02 Thread Ron Johnson
llers w/ 512MB battery- backed cache each, for a total of 1GB cache are easily available) disk subsystem for however many smaller CPU-boxes you get. (They could be kept un-shared by making separate partitions, and each machine only mounts one partition.) -- ----

Re: [PERFORM] Postgres low end processing.

2003-10-03 Thread Ron Johnson
thrash (in the literal sense) the page files. *No* work will get done. -- - Ron Johnson, Jr. [EMAIL PROTECTED] Jefferson, LA USA "...always eager to extend a friendly claw" ---(end of broadcast)-