Re: [HACKERS] stats_block_level
\On Jul 29, 2007, at 9:37 AM, Tom Lane wrote: Erik Jones <[EMAIL PROTECTED]> writes: improvement that went into that release. I could test turning it back on this week if you like -- I certainly would like to have my blks_read/cach_hits stats back. Toggling stats_block_level will respond to a reload, yes? Yes, as long as you had stats_start_collector on at startup. regards, tom lane Ok, we finally had a day with both our sysadmin and me in the office, flipped stats_block_level back on and noticed no noticable change in our iostats. We're going to leave it on and if anything starts to go crazy in the next couple of days I'll be sure to let you know. Erik Jones Software Developer | Emma® [EMAIL PROTECTED] 800.595.4401 or 615.292.5888 615.292.0777 (fax) Emma helps organizations everywhere communicate & market in style. Visit us online at http://www.myemma.com ---(end of broadcast)--- TIP 4: Have you searched our list archives? http://archives.postgresql.org
Re: [HACKERS] stats_block_level
On Jul 27, 2007, at 6:45 PM, Jim Nasby wrote: On Jul 26, 2007, at 2:03 PM, Tom Lane wrote: So maybe the *real* question to ask is why we have separate GUCs for stats_row_level and stats_block_level. Shouldn't we fold them into a single switch? It's hard to see what having just one of them turned on will save. IIRC, the guys at Emma have seen a performance difference with stats_block_level off and row_level on, presumable due in part to having 150k tables. Erik? Kim? Well, we turned it off at the same time we moved from 8.2.3 to 8.2.4 so the actual culprit may have been what prompted the stats collector improvement that went into that release. I could test turning it back on this week if you like -- I certainly would like to have my blks_read/cach_hits stats back. Toggling stats_block_level will respond to a reload, yes? Software Developer | Emma® [EMAIL PROTECTED] 800.595.4401 or 615.292.5888 615.292.0777 (fax) Emma helps organizations everywhere communicate & market in style. Visit us online at http://www.myemma.com ---(end of broadcast)--- TIP 7: You can help support the PostgreSQL project by donating at http://www.postgresql.org/about/donate
Re: [HACKERS] [GENERAL] Array assignment behavior (was Re: [ADMIN] Stored procedure
Ok, just so I can be sure I understand what I just read: i. says that you can assign to an array that has not been initialized. ii. states that the index of an insertion into an array should not be limited by the current range of index values of the array and requires any gaps in the index range to be set with values of null. I really don't have anything to add to discussion other than that I agree with Tom's assessment, but rather want clarify what might be a slightly hazy interpretation of the specs listed below. Tom Lane wrote: Actually, now that I look closely, I think the SQL spec demands exactly this. Recall that SQL99 only allows one-dimensional, lower-bound-one arrays. The specification for UPDATE ... SET C[I] = SV ... reads Case: i) If the value of C is null, then an exception condition is raised: data exception - null value in array target. ii) Otherwise: 1) Let N be the maximum cardinality of C. 2) Let M be the cardinality of the value of C. 3) Let I be the value of the immediately contained in . 4) Let EDT be the element type of C. 5) Case: A) If I is greater than zero and less than or equal to M, then the value of C is replaced by an array A with element type EDT and cardinality M derived as follows: I) For j varying from 1 (one) to I-1 and from I+1 to M, the j-th element in A is the value of the j-th element in C. II) The I-th element of A is set to the specified update value, denoted by SV, by applying the General Rules of Subclause 9.2, "Store assignment", to the I-th element of A and SV as TARGET and VALUE, respectively. B) If I is greater than M and less than or equal to N, then the value of C is replaced by an array A with element type EDT and cardinality I derived as follows: I) For j varying from 1 (one) to M, the j-th element in A is the value of the j-th element in C. II) For j varying from M+1 to I-1, the j-th element in A is the null value. III) The I-th element of A is set to the specified update value, denoted by SV, by applying the General Rules of Subclause 9.2, "Store assignment", to the I-th element of A and SV as TARGET and VALUE, respectively. C) Otherwise, an exception condition is raised: data exception - array element error. We currently violate case i by allowing the null array value to be replaced by a single-element array. I'm disinclined to change that, as I think our behavior is more useful than the spec's. But case ii.5.B pretty clearly describes null-fill, so I think we'd better do that, now that we can. regards, tom lane ---(end of broadcast)--- TIP 5: don't forget to increase your free space map settings -- erik jones <[EMAIL PROTECTED]> software development emma(r) ---(end of broadcast)--- TIP 1: if posting/reading through Usenet, please send an appropriate subscribe-nomail command to [EMAIL PROTECTED] so that your message can get through to the mailing list cleanly
Re: [HACKERS] [GENERAL] Array assignment behavior (was Re: [ADMIN] Stored procedure
Yep, that definitely threw me the first time I encountered it. Paul B. Anderson wrote: It seems that the suggestion to fill intermediate positions with NULLs would be preferable to the current behavior. I know of no requirement to populate arrays in sequence in any other language so I think other programmers would be surprised too by the current behavior. Paul Tom Lane wrote: [ expanding this thread, as it now needs wider discussion ] "Paul B. Anderson" <[EMAIL PROTECTED]> writes: Actually, I was not filling all of the arrays in sequential order. I added code to initialize them in order and the function seems to be working now. Is that a known problem? Well, it's a documented behavior: section 8.10.4 saith A stored array value can be enlarged by assigning to an element adjacent to those already present, or by assigning to a slice that is adjacent to or overlaps the data already present. Up to 8.2 we didn't have a lot of choice about this, because without any ability to have nulls embedded in arrays, there wasn't any sane thing to do with the intermediate positions if you assigned to an element not adjacent to the existing range. As of 8.2 we could allow assignment to arbitrary positions by filling the intermediate positions with nulls. The code hasn't actually been changed to allow that, but it's something we could consider doing now. Comments? regards, tom lane ---(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 . -- erik jones <[EMAIL PROTECTED]> software development emma(r) ---(end of broadcast)--- TIP 5: don't forget to increase your free space map settings
