Re: [PERFORM] Compare rows

2003-10-08 Thread Josh Berkus
Chris, > Some time in the late '80s, probably '88 or '89, there was a paper > presented in Communications of the ACM that proposed using this sort > of "hypernormalized" schema as a way of having _really_ narrow schemas > that would be exceedingly expressive. They illustrated an example of > The

Re: [HACKERS] [PERFORM] Sun performance - Major discovery!

2003-10-08 Thread Tom Lane
---(end of broadcast)--- TIP 5: Have you checked our extensive FAQ? http://www.postgresql.org/docs/faqs/FAQ.html

Re: [HACKERS] [PERFORM] Sun performance - Major discovery!

2003-10-08 Thread Bruce Momjian
Tom Lane wrote: > Neil Conway <[EMAIL PROTECTED]> writes: > > On Wed, 2003-10-08 at 14:31, Bruce Momjian wrote: > >> Well, this is really embarassing. I can't imagine why we would not set > >> at least -O on all platforms. > > I believe that autoconf will automatically select -O2 (when CFLAGS isn

Re: [PERFORM] Compare rows

2003-10-08 Thread Christopher Browne
In an attempt to throw the authorities off his trail, [EMAIL PROTECTED] (Josh Berkus) transmitted: > child table > idvalue_type value > 3 uptime 0.3 > 3 speed 11.2 > 3 memory 37 > 3 tty 6 > 7 uptime 1.1 > 7 m

Re: [HACKERS] [PERFORM] Sun performance - Major discovery!

2003-10-08 Thread Christopher Kings-Lynne
Well, this is really embarassing. I can't imagine why we would not set at least -O on all platforms. Looking at the template files, I see these have no optimization set: freebsd (non-alpha) I'm wondering what that had in mind: http://developer.postgresql.org/cvsweb.cgi/pgsql-server/src/temp

Re: [HACKERS] [PERFORM] Sun performance - Major discovery!

2003-10-08 Thread Bruce Momjian
Peter Eisentraut wrote: > Bruce Momjian writes: > > > Well, this is really embarassing. I can't imagine why we would not set > > at least -O on all platforms. Looking at the template files, I see > > these have no optimization set: > > > freebsd (non-alpha) > > I'm wondering what that had

Re: [PERFORM] Sun performance - Major discovery!

2003-10-08 Thread Bruce Momjian
Tom Lane wrote: > Neil Conway <[EMAIL PROTECTED]> writes: > > On Wed, 2003-10-08 at 14:31, Bruce Momjian wrote: > >> Well, this is really embarassing. I can't imagine why we would not set > >> at least -O on all platforms. > > I believe that autoconf will automatically select -O2 (when CFLAGS isn

Re: [PERFORM] Sun performance - Major discovery!

2003-10-08 Thread Tom Lane
Neil Conway <[EMAIL PROTECTED]> writes: > On Wed, 2003-10-08 at 14:31, Bruce Momjian wrote: >> Well, this is really embarassing. I can't imagine why we would not set >> at least -O on all platforms. I believe that autoconf will automatically select -O2 (when CFLAGS isn't already set) *if* it's ch

Re: [PERFORM] Presentation

2003-10-08 Thread Tom Lane
Jeff <[EMAIL PROTECTED]> writes: > On Wed, 8 Oct 2003, Neil Conway wrote: >> Slide 37: as far as I know, reordering of outer joins is not implemented >> in 7.4 > Huh. I could have sworn Tom did something like that. Not yet. 7.4 can reorder *inner* joins that happen to be written with JOIN syntax

Re: [PERFORM] Compare rows

2003-10-08 Thread Josh Berkus
Greg, > You lost me on that one. What's a "vertical child table"? Currently, you store data like this: id address uptime speed memory tty 3 67.92 0.3 11.237 6 7 69.51.1 NULL15 NULL 9 65.5

Re: [PERFORM] IMMUTABLE function's flag do not work: 7.3.4, plpgsql

2003-10-08 Thread Tom Lane
Andriy Tkachuk <[EMAIL PROTECTED]> writes: > At second. calc_total() is immutable function: > but it seems that it's not cached in one session: It's not supposed to be. The reason the "runtime" is small in your example is that the planner executes the function call while preparing the plan, and t

Re: [PERFORM] Presentation

2003-10-08 Thread Neil Conway
On Wed, 2003-10-08 at 15:38, Jeff wrote: > Huh. I could have sworn Tom did something like that. > Perhaps I am thinking of something else. > You had to enable some magic GUC. Perhaps you're thinking of the new GUC var join_collapse_limit, which is related, but doesn't effect the reordering of oute

Re: [PERFORM] PostgreSQL vs. MySQL

2003-10-08 Thread Vivek Khera
> "JB" == Josh Berkus <[EMAIL PROTECTED]> writes: JB> Hmmm ... both, I think. The Install Docs should have: JB> "Here are the top # things you will want to adjust in your PostgreSQL.conf: JB> 1) Shared_buffers JB> 2) Sort_mem JB> 3) effective_cache_size JB> 4) random_page_cost JB> 5) Fs

Re: [PERFORM] Compare rows

2003-10-08 Thread Dror Matalon
Greg, On Wed, Oct 08, 2003 at 03:07:30PM -0400, Greg Spiegelberg wrote: > Dror, > > I gave this some serious thought at first. I only deal with > int8, numeric(24,12) and varchar(32) columns which I could > reduce to 3 different tables. Problem was going from 1700-3000 I'm not sure how the dat

Re: [PERFORM] Presentation

2003-10-08 Thread Jeff
On Wed, 8 Oct 2003, Neil Conway wrote: > On Wed, 2003-10-08 at 11:02, Jeff wrote: > > The boss cleared my de-company info-ified pg presentation. > > Slide 37: as far as I know, reordering of outer joins is not implemented > in 7.4 > Huh. I could have sworn Tom did something like that. Perhaps I a

Re: [PERFORM] Compare rows

2003-10-08 Thread Jean-Luc Lachance
Here is what i think you can use: One master table with out duplicates and one anciliary table with duplicate for the day. Insert the result of the select from the anciliary table into the master table, truncate the anciliary table. select distinct on ( {all the fields except day}) * from table

Re: [PERFORM] Compare rows

2003-10-08 Thread Jason Hihn
> -Original Message- > From: [EMAIL PROTECTED] > [mailto:[EMAIL PROTECTED] Behalf Of Greg > Spiegelberg > Sent: Wednesday, October 08, 2003 3:11 PM > To: PgSQL Performance ML > Subject: Re: [PERFORM] Compare rows > > > Josh Berkus wrote: > > Greg, > > > > > >>The data represents metri

Re: [PERFORM] Sun performance - Major discovery!

2003-10-08 Thread pgsql-performance
In message <[EMAIL PROTECTED]>, Jeff writes: I'll go run the regression test suite with my gcc -O2 pg and the suncc pg. See if they pass the test. My default set of gcc optimization flags is: -O3 -funroll-loops -frerun-cse-after-loop -frerun-loop-opt -falign-functions -mcpu=i686 -march

Re: [PERFORM] Compare rows

2003-10-08 Thread Greg Spiegelberg
Josh Berkus wrote: Greg, The data represents metrics at a point in time on a system for network, disk, memory, bus, controller, and so-on. Rx, Tx, errors, speed, and whatever else can be gathered. We arrived at this one 642 column table after testing the whole process from data gathering, method

Re: [PERFORM] Compare rows

2003-10-08 Thread Greg Spiegelberg
Dror, I gave this some serious thought at first. I only deal with int8, numeric(24,12) and varchar(32) columns which I could reduce to 3 different tables. Problem was going from 1700-3000 rows to around 300,000-1,000,000 rows per system per day that is sending data to our database. BTW, the int8

Re: [PERFORM] Compare rows

2003-10-08 Thread Dror Matalon
It's still not quite clear what you're trying to do. Many people's gut reaction is that you're doing something strange with so many columns in a table. Using your example, a different approach might be to do this instead: Day | Name | Value --+-+--- Oct 1 |

Re: [HACKERS] [PERFORM] Sun performance - Major discovery!

2003-10-08 Thread Jeff
On Wed, 8 Oct 2003, Neil Conway wrote: > ISTM the most legitimate reason for not enabling compilater > optimizations on a given compiler/OS/architecture combination is might > cause compiler errors / bad code generation. > > Can we get these optimizations enabled in time for the next 7.4 beta? It

Re: [PERFORM] Presentation

2003-10-08 Thread Neil Conway
On Wed, 2003-10-08 at 11:02, Jeff wrote: > The boss cleared my de-company info-ified pg presentation. Slide 37: as far as I know, reordering of outer joins is not implemented in 7.4 -Neil ---(end of broadcast)--- TIP 6: Have you searched our list

Re: [PERFORM] Compare rows

2003-10-08 Thread Greg Spiegelberg
Joe Conway wrote: Greg Spiegelberg wrote: The reason for my initial question was this. We save changes only. In other words, if system S has row T1 for day D1 and if on day D2 we have another row T1 (excluding our time column) we don't want to save it. It still isn't entirely clear to me what y

Re: [PERFORM] Sun performance - Major discovery!

2003-10-08 Thread Neil Conway
On Wed, 2003-10-08 at 14:31, Bruce Momjian wrote: > Well, this is really embarassing. I can't imagine why we would not set > at least -O on all platforms. ISTM the most legitimate reason for not enabling compilater optimizations on a given compiler/OS/architecture combination is might cause compi

Re: [PERFORM] Sun performance - Major discovery!

2003-10-08 Thread Bruce Momjian
Jeff wrote: > On Wed, 8 Oct 2003, Neil Conway wrote: > > > > > What CFLAGS does configure pick for gcc? From > > src/backend/template/solaris, I'd guess it's not enabling any > > optimization. Is that the case? If so, some gcc numbers with -O and -O2 > > would be useful. > > > > I can't believe I

Re: [PERFORM] PostgreSQL vs. MySQL

2003-10-08 Thread Neil Conway
On Wed, 2003-10-08 at 14:05, Josh Berkus wrote: > Hmmm ... both, I think. The Install Docs should have: > > "Here are the top # things you will want to adjust in your PostgreSQL.conf: > 1) Shared_buffers > 2) Sort_mem > 3) effective_cache_size > 4) random_page_cost > 5) Fsync > etc." > Bar

Re: [PERFORM] Speeding up Aggregates

2003-10-08 Thread Dror Matalon
Actually what finally sovled the problem is repeating the dtstamp > last_viewed in the sub select select articlenumber, channel, description, title, link, dtstamp from items i1, my_channels where ((i1.channel = '2' and my_channels.id = '2' and owner = 'drormata' and (dtstamp > last_vi

Re: [PERFORM] PostgreSQL vs. MySQL

2003-10-08 Thread Bruce Momjian
Totally agree. --- Josh Berkus wrote: > Bruce, > > > Yes, I think that is a good idea --- now, does it go in the install > > docs, or in the docs next to each GUC item? > > Hmmm ... both, I think. The Install Docs should

Re: [PERFORM] Sun performance - Major discovery!

2003-10-08 Thread Jeff
On Wed, 8 Oct 2003, Neil Conway wrote: > > What CFLAGS does configure pick for gcc? From > src/backend/template/solaris, I'd guess it's not enabling any > optimization. Is that the case? If so, some gcc numbers with -O and -O2 > would be useful. > I can't believe I didn't think of this before! he

Re: [PERFORM] PostgreSQL vs. MySQL

2003-10-08 Thread Josh Berkus
Bruce, > Yes, I think that is a good idea --- now, does it go in the install > docs, or in the docs next to each GUC item? Hmmm ... both, I think. The Install Docs should have: "Here are the top # things you will want to adjust in your PostgreSQL.conf: 1) Shared_buffers 2) Sort_mem 3) effect

Re: [PERFORM] Compare rows

2003-10-08 Thread Greg Spiegelberg
See below. Shridhar Daithankar wrote: Greg Spiegelberg wrote: The data represents metrics at a point in time on a system for network, disk, memory, bus, controller, and so-on. Rx, Tx, errors, speed, and whatever else can be gathered. We arrived at this one 642 column table after testing the whol

Re: [PERFORM] Sun performance - Major discovery!

2003-10-08 Thread Neil Conway
On Wed, 2003-10-08 at 11:46, Jeff wrote: > Yeah - like I expected it was able to generate much better code for > _bt_checkkeys which was the #1 function in gcc on both sun & linux. > > and as you can see, suncc was just able to generate much nicer code. What CFLAGS does configure pick for gcc? Fr

Re: [PERFORM] Compare rows

2003-10-08 Thread Jason Hihn
Comment interjected below. > -Original Message- > From: [EMAIL PROTECTED] > [mailto:[EMAIL PROTECTED] Behalf Of Greg > Spiegelberg > Sent: Wednesday, October 08, 2003 12:28 PM > To: PgSQL Performance ML > Subject: Re: [PERFORM] Compare rows > > > Josh Berkus wrote: > > Greg, > > > > > >>An

Re: [PERFORM] Compare rows

2003-10-08 Thread Josh Berkus
Greg, > The data represents metrics at a point in time on a system for > network, disk, memory, bus, controller, and so-on. Rx, Tx, errors, > speed, and whatever else can be gathered. > > We arrived at this one 642 column table after testing the whole > process from data gathering, methods of tem

Re: [PERFORM] Presentation

2003-10-08 Thread Jeff
On Wed, 8 Oct 2003, Shridhar Daithankar wrote: > * Same slide. IIRC postgresql always compresses bytea/varchar. Not too much sure > about which but there is something that is compressed by default..:-) > * Tablespaces has a patch floating somewhere. IIRC Gavin Sherry is the one who > is most ahea

Re: [PERFORM] Compare rows

2003-10-08 Thread Joe Conway
Greg Spiegelberg wrote: The reason for my initial question was this. We save changes only. In other words, if system S has row T1 for day D1 and if on day D2 we have another row T1 (excluding our time column) we don't want to save it. It still isn't entirely clear to me what you are trying to do,

Re: [PERFORM] Sun performance - Major discovery!

2003-10-08 Thread Neil Conway
On Wed, 2003-10-08 at 10:48, Andrew Sullivan wrote: > My worry about this test is that it gives us precious little > knowledge about concurrent connection slowness, which is where I find > the most significant problems. As Jeff points out, the second set of results is for 20 concurrent connections

Re: [PERFORM] Compare rows

2003-10-08 Thread Shridhar Daithankar
Greg Spiegelberg wrote: The data represents metrics at a point in time on a system for network, disk, memory, bus, controller, and so-on. Rx, Tx, errors, speed, and whatever else can be gathered. We arrived at this one 642 column table after testing the whole process from data gathering, methods

Re: [PERFORM] Presentation

2003-10-08 Thread Jeff
On Wed, 8 Oct 2003, Shridhar Daithankar wrote: Thanks for the nitpicks :) I've taken some into consideration. I also signed onto the advocacy list so I can be in on discussions there. Feel free to convert to whatever format you'd like. I originally started working on it in OpenOffice, but I got

Re: [PERFORM] Compare rows

2003-10-08 Thread Greg Spiegelberg
Josh Berkus wrote: Greg, Anyone have any suggestions on how to efficiently compare rows in the same table? This table has 637 columns to be compared and 642 total columns. 637 columns? Are you sure that's normalized? It's hard for me to conceive of a circumstance where that many columns w

Re: [PERFORM] Compare rows

2003-10-08 Thread Josh Berkus
Greg, > Anyone have any suggestions on how to efficiently compare > rows in the same table? This table has 637 columns to be > compared and 642 total columns. 637 columns? Are you sure that's normalized? It's hard for me to conceive of a circumstance where that many columns would be necessa

Re: [PERFORM] Presentation

2003-10-08 Thread Josh Berkus
Jeff, > Its avail in powerpoint and (ugg) powerpoint exported html. I can probably convert it to OpenOffice.org and Flash. OK? -- Josh Berkus Aglio Database Solutions San Francisco ---(end of broadcast)--- TIP 2: you can get off all lists at onc

Re: [PERFORM] Presentation

2003-10-08 Thread Rod Taylor
> * Same slide. IIRC postgresql always compresses bytea/varchar. Not too much sure > about which but there is something that is compressed by default..:-) I'm not sure about that. Even toasted values are not always compressed, though they certainly can be and usually are. signature.asc Descrip

Re: [PERFORM] Presentation

2003-10-08 Thread Shridhar Daithankar
Jeff wrote: Let me know if there are blatant errors, etc in there. Maybe even slightly more subtle blatant errors :) Some minor nitpicks, * Slide 5, postgresql already features 64 bit port. The sentence is slightly confusing * Same slide. IIRC postgresql always compresses bytea/varchar. Not too m

Re: [PERFORM] Sun performance - Major discovery!

2003-10-08 Thread Jeff
On Wed, 8 Oct 2003, Neil Conway wrote: > Interesting (and surprising that the performance differential is that > large, to me at least). Can you tell if the performance gain comes from > an improvement in a particular subsystem? (i.e. could you get a profile > of Sun/gcc and compare it with Sun/su

Re: [PERFORM] planner doesn't use multicolumn index

2003-10-08 Thread Manfred Koizar
On Wed, 8 Oct 2003 09:08:59 -0500 (CDT), Adrian Demaestri <[EMAIL PROTECTED]> wrote: >the type of the fields are int2 and >int4, the where condition is v.g. partido=99 and partida=123). Write your search condition as WHERE partido=99::int2 and partida=123 Servus Manfred ---

[PERFORM] Presentation

2003-10-08 Thread Jeff
The boss cleared my de-company info-ified pg presentation. It deals with PG features, crude comparison to other dbs, install, admin, and most importantly - optimization & quirks. Its avail in powerpoint and (ugg) powerpoint exported html. Let me know if there are blatant errors, etc in there. May

Re: [PERFORM] Sun performance - Major discovery!

2003-10-08 Thread Jeff
On Wed, 8 Oct 2003, Neil Conway wrote: > What is the query? > It retrieves an index listing for our boards. The boards are flat (not threaded) and messages are numbered starting at 1 for each board. If you pass in 0 for the start_from it assumes the latest 60. And it should be noted - in some c

Re: [PERFORM] Sun performance - Major discovery!

2003-10-08 Thread Jeff
On Wed, 8 Oct 2003, Andrew Sullivan wrote: > My worry about this test is that it gives us precious little > knowledge about concurrent connection slowness, which is where I find > the most significant problems. When we tried a Sunsoft cc vs gcc 2.95 > on Sol 7 about 1 1/2 years ago, we found more

Re: [PERFORM] Speeding up Aggregates

2003-10-08 Thread Greg Stark
Rod Taylor <[EMAIL PROTECTED]> writes: > On Fri, 2003-10-03 at 17:53, Dror Matalon wrote: > > On Fri, Oct 03, 2003 at 05:44:49PM -0400, Rod Taylor wrote: > > > > > > It is too bad the (channel, link) index doesn't have dtstamp at the end > > > of it, otherwise the below query would be a gain (migh

Re: [PERFORM] Sun performance - Major discovery!

2003-10-08 Thread Neil Conway
On Wed, 2003-10-08 at 08:36, Jeff wrote: > So here's the results using my load tester (single connection per beater, > repeats the query 1000 times with different input each time (we'll get > ~20k rows back), the query is a common query around here. What is the query? > Linux - 1x - 35 seconds, 2

Re: [PERFORM] Sun performance - Major discovery!

2003-10-08 Thread Andrew Sullivan
On Wed, Oct 08, 2003 at 08:36:56AM -0400, Jeff wrote: > > So here's the results using my load tester (single connection per beater, > repeats the query 1000 times with different input each time (we'll get > ~20k rows back), the query is a common query around here. My worry about this test is that

Re: [PERFORM] planner doesn't use multicolumn index

2003-10-08 Thread Shridhar Daithankar
Adrian Demaestri wrote: We've a table with about 8 million rows, and we need to get rows by the value >of two of its fields( the type of the fields are int2 and int4, the where condition is v.g. partido=99 and partida=123). We created a >multicolumn index on that fields but the planner doesn't us

Re: [PERFORM] planner doesn't use multicolumn index

2003-10-08 Thread Tomasz Myrta
We've a table with about 8 million rows, and we need to get rows by the value of two of its fields( the type of the fields are int2 and int4, the where condition is v.g. partido=99 and partida=123). We created a multicolumn index on that fields but the planner doesn't use it, it still use a seq

[PERFORM] planner doesn't use multicolumn index

2003-10-08 Thread Adrian Demaestri
We've a table with about 8 million rows, and we need to get rows by the value of two of its fields( the type of the fields are int2 and int4, the where condition is v.g. partido=99 and partida=123). We created a multicolumn index on that fields but the planner doesn't use it, it still use a seqscan

[PERFORM] Compare rows

2003-10-08 Thread Greg Spiegelberg
All, Anyone have any suggestions on how to efficiently compare rows in the same table? This table has 637 columns to be compared and 642 total columns. TIA, Greg -- Greg Spiegelberg Sr. Product Development Engineer Cranel, Incorporated. Phone: 614.318.4314 Fax: 614.431.8388 Email: [EMAIL P

[PERFORM] IMMUTABLE function's flag do not work: 7.3.4, plpgsql

2003-10-08 Thread Andriy Tkachuk
Hi folks. I notice that immutable flag does nothing when i invoke my plpgsql function within one session with same args. tele=# SELECT version(); version - PostgreSQL 7.3.4 on i686-pc-linux-gnu, compiled by GC

[PERFORM] Sun performance - Major discovery!

2003-10-08 Thread Jeff
Well, as you guys know I've been tinkering with sun-vs-linux postgres for a while trying to come up with reasons for the HUGE performance differences. We've all had our anecdotal thoughts (fork sucks, ipc sucks, ufs sucks, etc) and I've had a breakthrough. Knowing that GCC only produces good code