Re: [HACKERS] New tzdata available
Magnus Hagander <[EMAIL PROTECTED]> writes: > On Fri, 2007-11-09 at 02:26 -0500, Tom Lane wrote: >> Plan B would be to take out contracts on all the banana-republic >> politicians who think that changing DST laws with a month's notice >> is a pleasant pastime. I fear we lack the resources for that, >> unfortunately. > You're referring to countries like the United States and New Zealand ;-) Be fair --- the USA did give us a couple years' notice. Though I'm still prepared to vote against any congresscritter who stands up and says that was a good idea. (I'm still driving a car whose GPS does not know about the change, and if any political animal happens to be reading this: it is not a good idea to tick off your constituents in the week before November elections.) > On a more serious note, we *could* make a simple ZIP file available with > files to drop in the timezone directory for such urgent updates, since > the majority of users don't need them. Sure, it's doable if anyone cares that much. But I think we should spend more energy on scheming how not to be involved. regards, tom lane ---(end of broadcast)--- TIP 7: You can help support the PostgreSQL project by donating at http://www.postgresql.org/about/donate
Re: [HACKERS] [PERFORM] Estimation problem with a LIKE clause containing a /
On Nov 9, 2007 3:08 AM, Tom Lane <[EMAIL PROTECTED]> wrote: > This rule works for all the locales I have installed ... but I don't > have any Far Eastern locales installed. Also, my test cases are only > covering ASCII characters, and I believe many locales have some non-ASCII > letters that sort after 'Z'. I'm not sure how hard we need to try to > cover those corner cases, though. It is ultimately only an estimate... My opinion is that it's acceptable to fix the problem for most cases in most locales because, as you said, it's only an estimate. We didn't have any report of this problem for years so it seems that it's not a common case or at least it's not common that the bad estimate leads to noticeably bad plans. As far as I understand what you plan to do, it doesn't seem to be something that prevents us to fix the problem afterwards if someone comes with an example which doesn't fit in the schema you're proposing and has a real performance problem with it. -- Guillaume ---(end of broadcast)--- TIP 3: Have you checked our extensive FAQ? http://www.postgresql.org/docs/faq
Re: [HACKERS] Free Space Map thoughts
On Thu, 2007-11-08 at 23:04 +, Gregory Stark wrote: > "Simon Riggs" <[EMAIL PROTECTED]> writes: > > > The pages might well be in cache, so the file location might well be > > irrelevant from an I/O perspective. Maybe. The nth page solution allows > > the FSM block to be easily located without any FSM index, so might well > > be faster. Separate files mean more space and more fsyncs too. But even > > so, I'm not sure either way. > > I don't follow any of the logical leaps in this paragraph. I asked Heikki to explain why he felt the design should go a certain way, which he didn't do. That's the logical leap I'm worried about. I repeat: I'm not sure either way. -- Simon Riggs 2ndQuadrant http://www.2ndQuadrant.com ---(end of broadcast)--- TIP 4: Have you searched our list archives? http://archives.postgresql.org
Re: [HACKERS] New tzdata available
On Fri, 2007-11-09 at 02:26 -0500, Tom Lane wrote: > Magnus Hagander <[EMAIL PROTECTED]> writes: > > On Thu, Nov 08, 2007 at 05:46:08PM -0800, Trevor Talbot wrote: > >> I've been wondering lately why it isn't just stored in the database > >> somewhere. > > > That's a different question. One reason is that we wanted files compatible > > with the stuff that was included in the zic library. > > I think the one lesson we have entirely absorbed is that we don't want > to be in-the-loop for timezone updates. I don't see how keeping the > info "inside" the DB would help that. Yeah. > Plan B would be to take out contracts on all the banana-republic > politicians who think that changing DST laws with a month's notice > is a pleasant pastime. I fear we lack the resources for that, > unfortunately. You're referring to countries like the United States and New Zealand ;-) On a more serious note, we *could* make a simple ZIP file available with files to drop in the timezone directory for such urgent updates, since the majority of users don't need them. But then still update to the latest TZ data whenever we release, and possibly still do TZ-related releases for cases when it's a large country (like the US...) that make the change... Seems reasonable? //Magnus ---(end of broadcast)--- TIP 2: Don't 'kill -9' the postmaster
Re: [HACKERS] New tzdata available
Magnus Hagander <[EMAIL PROTECTED]> writes: > On Thu, Nov 08, 2007 at 05:46:08PM -0800, Trevor Talbot wrote: >> I've been wondering lately why it isn't just stored in the database >> somewhere. > That's a different question. One reason is that we wanted files compatible > with the stuff that was included in the zic library. I think the one lesson we have entirely absorbed is that we don't want to be in-the-loop for timezone updates. I don't see how keeping the info "inside" the DB would help that. Plan B would be to take out contracts on all the banana-republic politicians who think that changing DST laws with a month's notice is a pleasant pastime. I fear we lack the resources for that, unfortunately. regards, tom lane ---(end of broadcast)--- TIP 6: explain analyze is your friend
Re: [HACKERS] New tzdata available
On Thu, Nov 08, 2007 at 05:46:08PM -0800, Trevor Talbot wrote: > On 11/8/07, Magnus Hagander <[EMAIL PROTECTED]> wrote: > > > Andrew Dunstan wrote: > > > Tom Lane wrote: > > > >> Are Windows users accustomed to having up-to-the-minute timezone > > >> information? Maybe there's something I don't know about Microsoft's > > >> update practices, but I would have thought that the expectations on that > > >> platform would be pretty darn low. > > > > No, they push updates fairly aggressively. Of course, that's when they > > > have fixes for the problems ... but I would normally expect them to be > > > well on top of timezone changes. > > > At least for "common places". They certainly pushed out TZ updates for > > the US changes and the NZ changes recently through their Windows > > Update/Automatic Updates/WSUS service. > > Unfortunately, until Vista there was no architecture in place to track > historical changes. On older versions, the latest zone calendar is > the one that's in effect for all dates (so current US rules apply to > last year's dates too, and we get inaccurate times for them). The OS > services aren't suitable as a replacement for tzdata. That only goes to *what* they update ;-) And the Windows timezone handling in general is very very limited, which is one of the reasons we went with doing our own timezone library in the first place. They still give you the latest updates quickly, which is what was Toms question. > I've been wondering lately why it isn't just stored in the database somewhere. That's a different question. One reason is that we wanted files compatible with the stuff that was included in the zic library. IIRC there was other reasons as well, but I don't remember what they were :-) //Magnus ---(end of broadcast)--- TIP 4: Have you searched our list archives? http://archives.postgresql.org
Re: [HACKERS] How to determine if psql returns ZERO to the "shell" and finished successfully?
Tommy wrote:
Hello,
I'm implementing a Setup Wizard to install PostgreSQL. In the documentation
it states that psql returns ZERO to the "shell" if it finished successfully.
I'm implementing a wizard in Pascal and was wondering the correct syntax to
check whether or not the shell received ZERO?
For example,
If not (psql) then
MsgBox('Note: psql was not finished normally.', mbError, MB_OK);
How exactly can I check to see if psql returns ZERO to the "shell"? What do
I test for? If(Psql.exe)? or is there a variable I can check to see if it
has been set?
You would check the same way you check for the exit status of any other
command you spawn.
Since you haven't told us what OS this is nor how your wizard is calling
psql, it's hard to say more.
cheers
andrew
---(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
[HACKERS] How to determine if psql returns ZERO to the "shell" and finished successfully?
Hello,
I'm implementing a Setup Wizard to install PostgreSQL. In the documentation
it states that psql returns ZERO to the "shell" if it finished successfully.
I'm implementing a wizard in Pascal and was wondering the correct syntax to
check whether or not the shell received ZERO?
For example,
If not (psql) then
MsgBox('Note: psql was not finished normally.', mbError, MB_OK);
How exactly can I check to see if psql returns ZERO to the "shell"? What do
I test for? If(Psql.exe)? or is there a variable I can check to see if it
has been set?
Any suggestions would surely be appreciated. Thanks.
---(end of broadcast)---
TIP 7: You can help support the PostgreSQL project by donating at
http://www.postgresql.org/about/donate
Re: [HACKERS] [PERFORM] Estimation problem with a LIKE clause containing a /
I wrote: > I did do some experimentation and found that among the ASCII characters > (ie, codes 32-126), nearly all the non-C locales on my Fedora machine > sort Z last and z next-to-last or vice versa. Most of the remainder > sort digits last and z or Z as the last non-digit character. Since Z is > not that close to the end of the sort order in C locale, however, z > seems the best bet. With still further experimentation, it seems that doesn't work very well, because the locales that sort digits last also seem not to discriminate against digits in their first pass. What did seem to work was: * Determine which of the strings "Z", "z", "y", "9" is seen as largest by strcoll(). * Append this string to the given input. * Search (using the CVS-HEAD make_greater_string logic) for a string greater than that. This rule works for all the locales I have installed ... but I don't have any Far Eastern locales installed. Also, my test cases are only covering ASCII characters, and I believe many locales have some non-ASCII letters that sort after 'Z'. I'm not sure how hard we need to try to cover those corner cases, though. It is ultimately only an estimate... regards, tom lane ---(end of broadcast)--- TIP 5: don't forget to increase your free space map settings
Re: [HACKERS] New tzdata available
On 11/8/07, Magnus Hagander <[EMAIL PROTECTED]> wrote: > Andrew Dunstan wrote: > > Tom Lane wrote: > >> Are Windows users accustomed to having up-to-the-minute timezone > >> information? Maybe there's something I don't know about Microsoft's > >> update practices, but I would have thought that the expectations on that > >> platform would be pretty darn low. > > No, they push updates fairly aggressively. Of course, that's when they > > have fixes for the problems ... but I would normally expect them to be > > well on top of timezone changes. > At least for "common places". They certainly pushed out TZ updates for > the US changes and the NZ changes recently through their Windows > Update/Automatic Updates/WSUS service. Unfortunately, until Vista there was no architecture in place to track historical changes. On older versions, the latest zone calendar is the one that's in effect for all dates (so current US rules apply to last year's dates too, and we get inaccurate times for them). The OS services aren't suitable as a replacement for tzdata. I've been wondering lately why it isn't just stored in the database somewhere. ---(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] Free Space Map thoughts
Simon Riggs wrote: > Presumably we would not store an FSM for small tables? On the basis that > the purpose of the FSM is to save on pointless I/O there must be a size > of table below which an FSM is just overhead. Hmm, do you mean that we would open and verify every page of a small relation until we find one with free space? That doesn't sound very good. -- Alvaro Herrerahttp://www.CommandPrompt.com/ The PostgreSQL Company - Command Prompt, Inc. ---(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
Re: [HACKERS] [PERFORM] Estimation problem with a LIKE clause containing a /
Gregory Stark <[EMAIL PROTECTED]> writes: > Doesn't really strike at the core reason that this is so klugy though. Surely > the "right" thing is to push the concept of open versus closed end-points > through deeper into the estimation logic? No, the right thing is to take the folk who defined "dictionary sort order" out behind the barn and shoot 'em ;-). This has got nothing to do with open/closed endpoints and everything to do with the bizarre sorting rules used by some locales. In particular the reason I want to append a letter is that some locales discriminate against non-letter characters in the first pass of sorting. I did do some experimentation and found that among the ASCII characters (ie, codes 32-126), nearly all the non-C locales on my Fedora machine sort Z last and z next-to-last or vice versa. Most of the remainder sort digits last and z or Z as the last non-digit character. Since Z is not that close to the end of the sort order in C locale, however, z seems the best bet. regards, tom lane ---(end of broadcast)--- TIP 2: Don't 'kill -9' the postmaster
Re: [HACKERS] [PERFORM] Estimation problem with a LIKE clause containing a /
"Tom Lane" <[EMAIL PROTECTED]> writes: > What I am tempted to do about this is have make_greater_string tack "zz" > onto the supplied prefix, so that it would have to find a string that > compares greater than "123/zz" before reporting success. This is > getting pretty klugy though, so cc'ing to pgsql-hackers to see if anyone > has a better idea. Hm, instead of "zz" is there a convenient way to find out what actual character sorts last amongst all the single characters in the locale's encoding? Doesn't really strike at the core reason that this is so klugy though. Surely the "right" thing is to push the concept of open versus closed end-points through deeper into the estimation logic? -- Gregory Stark EnterpriseDB http://www.enterprisedb.com Ask me about EnterpriseDB's RemoteDBA services! ---(end of broadcast)--- TIP 3: Have you checked our extensive FAQ? http://www.postgresql.org/docs/faq
Re: [HACKERS] Free Space Map thoughts
"Simon Riggs" <[EMAIL PROTECTED]> writes: > The pages might well be in cache, so the file location might well be > irrelevant from an I/O perspective. Maybe. The nth page solution allows > the FSM block to be easily located without any FSM index, so might well > be faster. Separate files mean more space and more fsyncs too. But even > so, I'm not sure either way. I don't follow any of the logical leaps in this paragraph. [We talked about this...] Why would having the FSM info be physically addressed into every nth page of the heap allow FSM blocks to be more easily found than having them be physically addressed in a separate file? Why would separate files mean more space or more fsyncs? > Presumably we would not store an FSM for small tables? On the basis that > the purpose of the FSM is to save on pointless I/O there must be a size > of table below which an FSM is just overhead. That's one of the advantages of using separate files. It would be easy to have or not have a whole file. It would be pretty hard to know whether the bits spread on every nth page are missing and hard to add them later if the table grows and they're needed. -- Gregory Stark EnterpriseDB http://www.enterprisedb.com Ask me about EnterpriseDB's PostGIS support! ---(end of broadcast)--- TIP 7: You can help support the PostgreSQL project by donating at http://www.postgresql.org/about/donate
Re: [HACKERS] New tzdata available
Andrew Dunstan wrote: > > > Tom Lane wrote: >> >> Are Windows users accustomed to having up-to-the-minute timezone >> information? Maybe there's something I don't know about Microsoft's >> update practices, but I would have thought that the expectations on that >> platform would be pretty darn low. >> >> >> > > No, they push updates fairly aggressively. Of course, that's when they > have fixes for the problems ... but I would normally expect them to be > well on top of timezone changes. At least for "common places". They certainly pushed out TZ updates for the US changes and the NZ changes recently through their Windows Update/Automatic Updates/WSUS service. //Magnus ---(end of broadcast)--- TIP 4: Have you searched our list archives? http://archives.postgresql.org
Re: [HACKERS] New tzdata available
Tom Lane wrote: Are Windows users accustomed to having up-to-the-minute timezone information? Maybe there's something I don't know about Microsoft's update practices, but I would have thought that the expectations on that platform would be pretty darn low. No, they push updates fairly aggressively. Of course, that's when they have fixes for the problems ... but I would normally expect them to be well on top of timezone changes. cheers andrew ---(end of broadcast)--- TIP 3: Have you checked our extensive FAQ? http://www.postgresql.org/docs/faq
Re: [HACKERS] Test lab
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On Sun, 04 Nov 2007 18:55:59 + Simon Riggs <[EMAIL PROTECTED]> wrote: ve up and have ready access to > > is a HP DL 585. It has 8 cores (Opteron), 32GB of ram and 28 > > spindles over 4 channels. > > > > My question is -hackers, is who wants first bite and what do they > > want :) > > I'll take a few slots, probably 3 x 1 days, at least a week apart. > Won't be able to start before 19th Nov. Sorry I missed this. We are awaiting provisioning. > > I want to look at scaling issues on some isolated workloads on > in-memory databases, as well as WAL writing. I'll generate the data > directly on the system. > > Any chance we can validate the I/O config and publish bonnie results > first, please? I don't see why not. Sincerely, Joshua D. Drake > - -- === The PostgreSQL Company: Command Prompt, Inc. === Sales/Support: +1.503.667.4564 24x7/Emergency: +1.800.492.2240 PostgreSQL solutions since 1997 http://www.commandprompt.com/ UNIQUE NOT NULL Donate to the PostgreSQL Project: http://www.postgresql.org/about/donate PostgreSQL Replication: http://www.commandprompt.com/products/ -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.6 (GNU/Linux) iD8DBQFHM4DiATb/zqfZUUQRAt6aAJ480a9kc4sQulVK75OkDqaMO9UIAQCdGt0u roOCT54brrIPcn6jPWsQEas= =Ca+e -END PGP SIGNATURE- ---(end of broadcast)--- TIP 4: Have you searched our list archives? http://archives.postgresql.org
Re: [HACKERS] Test lab
On Sun, 2007-11-04 at 18:55 +, Simon Riggs wrote: > On Fri, 2007-11-02 at 10:42 -0700, Joshua D. Drake wrote: > > > > My question is -hackers, is who wants first bite and what do they > > want :) > > I'll take a few slots, probably 3 x 1 days, at least a week apart. Won't > be able to start before 19th Nov. Should I take that as a Yes or a No? > Any chance we can validate the I/O config and publish bonnie results > first, please? Will you be posting details for access? -- Simon Riggs 2ndQuadrant http://www.2ndQuadrant.com ---(end of broadcast)--- TIP 6: explain analyze is your friend
Re: [HACKERS] New tzdata available
Magnus Hagander <[EMAIL PROTECTED]> writes: > Tom Lane wrote: >> For people using prebuilt packages, it's really the packager's problem. >> I think most packagers are going to move to depending on a system >> timezone DB if at all possible. > Still need a solution for those where it's not possible (hint: Windows). > Not saying it has to be what's there now, but there has to be something > workable. Are Windows users accustomed to having up-to-the-minute timezone information? Maybe there's something I don't know about Microsoft's update practices, but I would have thought that the expectations on that platform would be pretty darn low. regards, tom lane ---(end of broadcast)--- TIP 5: don't forget to increase your free space map settings
Re: [HACKERS] pg_statistic "forced" values
On Wed, 2007-11-07 at 17:18 +0100, Jacques Caron wrote: > It is well known that in some instances the Postgresql will make > estimates of the number of distinct values in a table that can be > quite far off reality. This then has a tendency to make the planner > lean towards unsavory plans (read: seqscans) because it estimates the > number of lines returned by a part of the request as being quite a > lot more than they really are. > > The "good" solution would be to fix the estimator, but there has > already been long discussions on this topic in the past years and > apparently no consensus was found, with alternatives proposed > "fixing" some cases where the current estimator is wrong but getting > in trouble in others, or requiring quite a bit more CPU/memory/disk > I/O to achieve their results (correct me if I'm wrong). > > There is a "simple" way to override this, which is to change the > value present in pg_statistic, however it will be overwritten the > next time ANALYZE (or VACUUM ANALYZE) is run. This thus requires > adding updates to this value every time a request that might be > fooled by it is executed, which is cumbersome, and does not > facilitate updates of this value (especially with positive values of > stadistinct). > > It seems to me it would be a good idea to be able to store a forced > value for stadistinct in pg_attribute (with optionally some clauses > to set/change/reset it in CREATE TABLE, ALTER TABLE ADD COLUMN and > ALTER TABLE ALTER COLUMN, in a way similar to the STATISTICS clauses). I'm looking at exactly this issue at the moment, though as one issue amongst many similar ones. My inclination is to decide what needs to be stored, then debate separately where it should be stored. I expect to post a wider proposal in around two weeks. -- Simon Riggs 2ndQuadrant http://www.2ndQuadrant.com ---(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
Re: [HACKERS] Free Space Map thoughts
On Thu, 2007-11-08 at 15:24 +, Heikki Linnakangas wrote: > I still feel the FSM should be in a file of it's own, rather than > distributed on every nth heap page. It makes scanning it quicker, > because it's sequential rather than random access, we're going to need > a > solution for indexes as well, and using the special area of heap > pages > would make the locking quite tricky. I'd like to see the analysis on each side of that decision, so we can decide openly. The pages might well be in cache, so the file location might well be irrelevant from an I/O perspective. Maybe. The nth page solution allows the FSM block to be easily located without any FSM index, so might well be faster. Separate files mean more space and more fsyncs too. But even so, I'm not sure either way. Presumably we would not store an FSM for small tables? On the basis that the purpose of the FSM is to save on pointless I/O there must be a size of table below which an FSM is just overhead. -- Simon Riggs 2ndQuadrant http://www.2ndQuadrant.com ---(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
Re: [HACKERS] fulltext parser strange behave
Andrew Dunstan wrote: Tom Lane wrote: Andrew Dunstan <[EMAIL PROTECTED]> writes: Tom Lane wrote: Well, the state machine definitely thinks that tag names should contain only ASCII letters (with possibly a leading or trailing '/'). Given the HTML examples I suppose we should allow non-first digits too. Is there anything else that should be considered a tag? What about dash and underscore for instance? The docs say we specifically accept HTML tags. Are we really just accepting anything that is a string of ASCII letters as the tag name? Then we should adjust the docs. and are not HTML tags. I don't think I want to try to maintain a list of exactly which identifiers are considered valid tag names ... and if I did, I wouldn't put it into the parser. It would be a dictionary's job to tell valid from invalid tag names, no? I don't have a quarrel with that. But then we should be more clear about what we are recognizing. We could describe the thing as an HTML-like tag, possibly. I think the same probably goes for entities too. I've just been looking at the state machine in wparser_def.c. I think the processing for entities is also a few bob short in the pound. It recognises decimal numeric character references, but nor hexadecimal numeric character references. That's fairly silly since the HTML spec specifically says the latter are "particularly useful". The rules for named entities are also deficient w.r.t. digits, just like the case of tags that Tom noticed. This isn't academic: HTML features a number of named entities with digits in the name (sup2, frac14 for example). In XML at least, legal names are defined by the following rules from the spec: [4] NameStartChar ::= ":" | [A-Z] | "_" | [a-z] | [#xC0-#xD6] | [#xD8-#xF6] | [#xF8-#x2FF] | [#x370-#x37D] | [#x37F-#x1FFF] | [#x200C-#x200D] | [#x2070-#x218F] | [#x2C00-#x2FEF] | [#x3001-#xD7FF] | [#xF900-#xFDCF] | [#xFDF0-#xFFFD] | [#x1-#xE] [4a] NameChar ::= NameStartChar | "-" | "." | [0-9] | #xB7 | [#x0300-#x036F] | [#x203F-#x2040] [5] Name ::= NameStartChar (NameChar)* Restricting this to ASCII, we get: [4] NameStartChar ::= ":" | [A-Z] | "_" | [a-z] [4a] NameChar ::= NameStartChar | "-" | "." | [0-9] [5] Name ::= NameStartChar (NameChar)* or this regex for Name: [A-Za-z:_][A-Za-z0-9:_.-]* I suggest we use that or something very close to it as the rule for names in these patterns. cheers andrew ---(end of broadcast)--- TIP 5: don't forget to increase your free space map settings
Re: [HACKERS] New tzdata available
Tom Lane wrote: > Alvaro Herrera <[EMAIL PROTECTED]> writes: >> Zdenek Kotala wrote: >>> I think we need some different mechanism how to deliver timezone updated. > >> Even when the system TZ is not used, we could deliver our "zic" >> executable (pgzic?) and let the user drop the latest tzdata somewhere >> and recompile it. > > Well, a person who builds from source has already got the zic program; > all we need do is document someplace (more visible than now) how to drop > the tzdata update into the source tree and reinstall the files. > > For people using prebuilt packages, it's really the packager's problem. > I think most packagers are going to move to depending on a system > timezone DB if at all possible. Still need a solution for those where it's not possible (hint: Windows). Not saying it has to be what's there now, but there has to be something workable. //Magnus ---(end of broadcast)--- TIP 2: Don't 'kill -9' the postmaster
[HACKERS] High Availability, Load Balancing, and Replication Feature Matrix
[ BCC to hackers.] I have added a High Availability, Load Balancing, and Replication Feature Matrix table to the docs: http://momjian.us/main/writings/pgsql/sgml/high-availability.html#HIGH-AVAILABILITY-MATRIX -- Bruce Momjian <[EMAIL PROTECTED]>http://momjian.us EnterpriseDB http://postgres.enterprisedb.com + If your life is a hard drive, Christ can be your backup. + ---(end of broadcast)--- TIP 4: Have you searched our list archives? http://archives.postgresql.org
Re: [HACKERS] A small rant about coding style for backend functions
Brendan Jurd wrote: > On Nov 9, 2007 3:17 AM, Bruce Momjian <[EMAIL PROTECTED]> wrote: > > We want patch submitters to spend their time on patches, not learning > > our style. The fact is that pgindent is a silver bullet in some ways. > > Well there's a lot of support for the idea of pgindent being good > enough to establish a consistent coding style. I personally think a > much higher target for consistency would be worth pursuing, but I can > tell when I'm outgunned. > > Maybe it would be more productive to drop the topic of code style (as > in whitespace/formatting) and stick to talking about code style (as in > GETARG). > > I've suggested that some more information on using ereport effectively > might be at home in such a list. Perhaps some advice about working > with varlenas (which macros you should use in given situations, > differentiating toasted and detoasted). > > Are there any items which patch reviewers find themselves repeating to > several different developers? Things that follow the form "Don't use > $foo, use $bar", or "We don't do $x anymore, do $y instead"? These > are the sorts of items that would really benefit from publication. I can't think of anything that isn't already in the developer's FAQ. > > My major contention is that any list is going to be very details and > > hard to read, and no one has put up a list disputing that. > > > > This complaint still puzzles me. Why would it be hard to read? > Wouldn't that have more to do with the way it is presented than what > it contains? If it turns out to be hard to read, that's just an > indication that it needs to be better formatted. This isn't > superstring theory. It's just some guidelines on how to write good > Postgres code. It is going to be lots of minutia that is going to be very unintersting and saying just follow the surrounding code is a better use of their time rather than reading a list. > Even if it were hard to read, reading a difficult document is pretty > much guaranteed to take less time than waiting on a full review cycle, > then reworking, recompiling, retesting and resubmitting your patch. We just don't see that happening much in practice. -- Bruce Momjian <[EMAIL PROTECTED]>http://momjian.us EnterpriseDB http://postgres.enterprisedb.com + If your life is a hard drive, Christ can be your backup. + ---(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
Re: [HACKERS] A small rant about coding style for backend functions
On Nov 9, 2007 3:17 AM, Bruce Momjian <[EMAIL PROTECTED]> wrote: > We want patch submitters to spend their time on patches, not learning > our style. The fact is that pgindent is a silver bullet in some ways. Well there's a lot of support for the idea of pgindent being good enough to establish a consistent coding style. I personally think a much higher target for consistency would be worth pursuing, but I can tell when I'm outgunned. Maybe it would be more productive to drop the topic of code style (as in whitespace/formatting) and stick to talking about code style (as in GETARG). I've suggested that some more information on using ereport effectively might be at home in such a list. Perhaps some advice about working with varlenas (which macros you should use in given situations, differentiating toasted and detoasted). Are there any items which patch reviewers find themselves repeating to several different developers? Things that follow the form "Don't use $foo, use $bar", or "We don't do $x anymore, do $y instead"? These are the sorts of items that would really benefit from publication. > > My major contention is that any list is going to be very details and > hard to read, and no one has put up a list disputing that. > This complaint still puzzles me. Why would it be hard to read? Wouldn't that have more to do with the way it is presented than what it contains? If it turns out to be hard to read, that's just an indication that it needs to be better formatted. This isn't superstring theory. It's just some guidelines on how to write good Postgres code. Even if it were hard to read, reading a difficult document is pretty much guaranteed to take less time than waiting on a full review cycle, then reworking, recompiling, retesting and resubmitting your patch. Cheers BJ ---(end of broadcast)--- TIP 3: Have you checked our extensive FAQ? http://www.postgresql.org/docs/faq
Re: [HACKERS] [PERFORM] Estimation problem with a LIKE clause containing a /
"Guillaume Smet" <[EMAIL PROTECTED]> writes: > On Nov 8, 2007 12:14 AM, Tom Lane <[EMAIL PROTECTED]> wrote: >> I've applied a patch that might help you: >> http://archives.postgresql.org/pgsql-committers/2007-11/msg00104.php > AFAICS, it doesn't seem to fix the problem. I just compiled > REL8_1_STABLE branch and I still has the following behaviour: OK, I tried it in fr_FR locale and what I find is that regression=# select '123/' < '1230'::text; ?column? -- t (1 row) so make_greater_string() will still think that its first try at generating an upper-bound string is good enough. However regression=# select '123/1' < '1230'::text; ?column? -- f (1 row) so the data starting with '123/' is still outside the generated range, leading to a wrong estimate. I didn't see this behavior yesterday but I was experimenting with en_US which I guess has different rules. What I am tempted to do about this is have make_greater_string tack "zz" onto the supplied prefix, so that it would have to find a string that compares greater than "123/zz" before reporting success. This is getting pretty klugy though, so cc'ing to pgsql-hackers to see if anyone has a better idea. regards, tom lane ---(end of broadcast)--- TIP 2: Don't 'kill -9' the postmaster
Re: [HACKERS] A small rant about coding style for backend functions
Alvaro Herrera <[EMAIL PROTECTED]> writes: > If someone submits a piece of code that's totally out of line with our > standards, we will ask him to resubmit. This step could be avoided if > he knew what those standards were in the first place. True, but "make it look like what you see" is more than enough detail for that purpose. We should not expend a lot of thought-bandwidth on details that pgindent can fix. > I also don't understand why pgindent is assumed to be some sort of > silver bullet to solve all our coding style problems. It certainly cannot fix high-level style issues, but issues like brace placement and indenting it can deal with; and that seems to be what too many people are talking about when they mention coding style. regards, tom lane ---(end of broadcast)--- TIP 2: Don't 'kill -9' the postmaster
Re: [HACKERS] Postgresql 8.3 beta crash
Peter Eisentraut <[EMAIL PROTECTED]> writes: > Am Mittwoch, 31. Oktober 2007 schrieb Sheikh Amjad: >> Following test case is crashing the postgresql-8.3-beta > Btw., I didn't forget this, but I haven't found an extended period of quiet > time to develop a proper solution. I fixed it a few days ago... regards, tom lane ---(end of broadcast)--- TIP 3: Have you checked our extensive FAQ? http://www.postgresql.org/docs/faq
Re: [HACKERS] A small rant about coding style for backend functions
Alvaro Herrera wrote: > > > Having said that, there are two or three tips worth knowing about > > > pg_indent's behavior, like when and how to use dashes to prevent > > > comment blocks from being re-flowed. But it's a short list. > > If someone submits a piece of code that's totally out of line with our > standards, we will ask him to resubmit. This step could be avoided if > he knew what those standards were in the first place. True, but 95% of the cases are submitters using the wrong functions, methods, etc, not the style. I don't remember us ever returning a patch for rework based on style issues alone. > PG_GETARG and the like are not fixed by pgindent though (which is what > spawned this whole discussion). And in-house code (or pgFondry code), > which could also benefit by our coding style, will not be processed by > pgindent anyway. > > > pgindent will the format code by specifying flags to your > > operating system's utility indent. This > > > "http://ezine.daemonnews.org/200112/single_coding_style.html";>article > > describes the value of a consistent coding style. > > I don't understand why would you link to an article about the value of > consistent coding style, and not provide a link to our own coding style. > > I also don't understand why pgindent is assumed to be some sort of > silver bullet to solve all our coding style problems. It is better if > we educate our developers instead of just having pgindent at the end of > the cycle deal with the messed up code. Up to now, this education has > been one individual at a time, but it is much better if we can scale in > a way that every individual wastes only his own time learning our rules. We want patch submitters to spend their time on patches, not learning our style. The fact is that pgindent is a silver bullet in some ways. My major contention is that any list is going to be very details and hard to read, and no one has put up a list disputing that. -- Bruce Momjian <[EMAIL PROTECTED]>http://momjian.us EnterpriseDB http://postgres.enterprisedb.com + If your life is a hard drive, Christ can be your backup. + ---(end of broadcast)--- TIP 2: Don't 'kill -9' the postmaster
Re: [HACKERS] A small rant about coding style for backend functions
Bruce Momjian wrote: > Tom Lane wrote: > > "Brendan Jurd" <[EMAIL PROTECTED]> writes: > > > If Postgres did have something akin to the Python C style guide, that > > > would be excellent. But all we've got is a standard tabstop of four > > > spaces and the five words "Our standard format BSD style". Don't you > > > think that comes across as pretty weak for a project of this size and > > > significance? > > > > The reason it's not necessary to be very explicit about that is simple: > > pg_indent. Your code *will* conform to the layout standards by the > > time it's released ;-). Now it's still a good idea to make new code > > look roughly like what you see there already, because if you go too > > far overboard in ignoring line-length or comment layout conventions, > > the code may look a bit awful when pg_indent gets done with it. > > But I see no need to burden authors with any advice more detailed > > than "make it look like what you see". > > > > Having said that, there are two or three tips worth knowing about > > pg_indent's behavior, like when and how to use dashes to prevent > > comment blocks from being re-flowed. But it's a short list. If someone submits a piece of code that's totally out of line with our standards, we will ask him to resubmit. This step could be avoided if he knew what those standards were in the first place. This doesn't have to be a bible on coding style. A few guidelines suffice. PG_GETARG and the like are not fixed by pgindent though (which is what spawned this whole discussion). And in-house code (or pgFondry code), which could also benefit by our coding style, will not be processed by pgindent anyway. > pgindent will the format code by specifying flags to your > operating system's utility indent. This "http://ezine.daemonnews.org/200112/single_coding_style.html";>article > describes the value of a consistent coding style. I don't understand why would you link to an article about the value of consistent coding style, and not provide a link to our own coding style. I also don't understand why pgindent is assumed to be some sort of silver bullet to solve all our coding style problems. It is better if we educate our developers instead of just having pgindent at the end of the cycle deal with the messed up code. Up to now, this education has been one individual at a time, but it is much better if we can scale in a way that every individual wastes only his own time learning our rules. -- Alvaro Herrera Valdivia, Chile ICBM: S 39º 49' 18.1", W 73º 13' 56.4" Thou shalt check the array bounds of all strings (indeed, all arrays), for surely where thou typest "foo" someone someday shall type "supercalifragilisticexpialidocious" (5th Commandment for C programmers) ---(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
Re: [HACKERS] New tzdata available
Alvaro Herrera <[EMAIL PROTECTED]> writes: > Zdenek Kotala wrote: >> I think we need some different mechanism how to deliver timezone updated. > Even when the system TZ is not used, we could deliver our "zic" > executable (pgzic?) and let the user drop the latest tzdata somewhere > and recompile it. Well, a person who builds from source has already got the zic program; all we need do is document someplace (more visible than now) how to drop the tzdata update into the source tree and reinstall the files. For people using prebuilt packages, it's really the packager's problem. I think most packagers are going to move to depending on a system timezone DB if at all possible. 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
Re: [HACKERS] New tzdata available
Zdenek Kotala wrote: > Devrim GÜNDÜZ napsal(a): >> Hi, >> ftp://elsie.nci.nih.gov/pub/tzdata2007i.tar.gz >> Per announcement: >> "...is now available; this reflects changes for Cuba and Syria >> circulated earlier this week on the time zone mailing list. >> There are no code changes, so there's no tzcode2007i; tzcood2007h >> remains current." > > I think we need some different mechanism how to deliver timezone updated. > Bump version and rebuild everything when new timezone files are released is > not good idea, especially in case when most unix packagers use system > timezone. Agreed. Even when the system TZ is not used, we could deliver our "zic" executable (pgzic?) and let the user drop the latest tzdata somewhere and recompile it. -- Alvaro Herrera Developer, http://www.PostgreSQL.org/ "¿Qué importan los años? Lo que realmente importa es comprobar que a fin de cuentas la mejor edad de la vida es estar vivo" (Mafalda) ---(end of broadcast)--- TIP 5: don't forget to increase your free space map settings
Re: [HACKERS] minimal update
Tom Lane wrote: Michael Glaesemann <[EMAIL PROTECTED]> writes: What would be the disadvantages of always doing this, i.e., just making this part of the normal update path in the backend? (1) cycles wasted to no purpose in the vast majority of cases. (2) visibly inconsistent behavior for apps that pay attention to ctid/xmin/etc. (3) visibly inconsistent behavior for apps that have AFTER triggers. There's enough other overhead in issuing an update (network, parsing/planning/etc) that a sanely coded application should try to avoid issuing no-op updates anyway. The proposed trigger is just a band-aid IMHO. I think having it as an optional trigger is a reasonable compromise. Right. I never proposed making this the default behaviour, for all these good reasons. The point about making the app try to avoid no-op updates is that this can impose some quite considerable code complexity on the app, especially where the number of updated fields is large. It's fragile and error-prone. A simple switch that can turn a trigger on or off will be nicer. Syntax support for that might be even nicer, but there appears to be some resistance to that, so I can easily settle for the trigger. cheers andrew ---(end of broadcast)--- TIP 4: Have you searched our list archives? http://archives.postgresql.org
Re: [HACKERS] Postgresql 8.3 beta crash
Am Mittwoch, 31. Oktober 2007 schrieb Sheikh Amjad: > Following test case is crashing the postgresql-8.3-beta > SELECT XMLELEMENT > ( NAME "Program", > XMLAGG > ( XMLELEMENT > ( NAME "Student", s.name::xml ) > ) > ) AS "Registered Student" > > >from st.student s ; Btw., I didn't forget this, but I haven't found an extended period of quiet time to develop a proper solution. -- Peter Eisentraut http://developer.postgresql.org/~petere/ ---(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
Re: [HACKERS] A small rant about coding style for backend functions
"Bruce Momjian" <[EMAIL PROTECTED]> writes: > Tom Lane wrote: > >> Having said that, there are two or three tips worth knowing about >> pg_indent's behavior, like when and how to use dashes to prevent >> comment blocks from being re-flowed. But it's a short list. > > Agreed, and the developer's FAQ already has this: > > pgindent will the format code by specifying flags to your What I would like to see are guidelines on the more important issues. Things like always using PG_GETARG_* and DatumGet* rather than explicitly calling pg_detoast_datum() and so on. Actually I'm not sure what else would fall under "and so on". -- Gregory Stark EnterpriseDB http://www.enterprisedb.com Ask me about EnterpriseDB's 24x7 Postgres support! ---(end of broadcast)--- TIP 4: Have you searched our list archives? http://archives.postgresql.org
[HACKERS] Free Space Map thoughts
I found a nice paper describing a few free space management algorithms: M. L. McAuliffe, M. J. Carey and M. H. Solomon, Towards Effective and Efficient Free Space Management, Proceedings of the ACM SIGMOD, Jun. 1996, pages 389--400. http://citeseer.ist.psu.edu/mcauliffe96towards.html The basic data structure used by all of the discussed algorithms is essentially a bitmap, with a few bits per each heap page, indicating the amount of free space on each page. Just like Tom suggested (http://archives.postgresql.org/pgsql-hackers/2007-11/msg00204.php). The paper calls this the Free Space Inventory Page, or FSIP. The problem is efficiently finding a page with X bytes from the FSIP. The algorithms surveyed in that paper aim to solve that problem, and they're all pretty simple. The general trick is to cache some of the information in the FSIP, so that you don't always have to linearly scan it. Another nice property of the FSIP is that you can quickly get a summary of the distribution of the free space, and sum of free space and utilization %. I still feel the FSM should be in a file of it's own, rather than distributed on every nth heap page. It makes scanning it quicker, because it's sequential rather than random access, we're going to need a solution for indexes as well, and using the special area of heap pages would make the locking quite tricky. I think we can, however, mix the visibility map with the FSM. The visibility map would be spread over many more pages that way, which might affect scan performance. But it'd also ease the potential lock contention of updates, and you could then update the FSM and the visibility map in one operation. Just thinking ahead... -- Heikki Linnakangas EnterpriseDB http://www.enterprisedb.com ---(end of broadcast)--- TIP 3: Have you checked our extensive FAQ? http://www.postgresql.org/docs/faq
Re: [HACKERS] A small rant about coding style for backend functions
Tom Lane wrote: > "Brendan Jurd" <[EMAIL PROTECTED]> writes: > > If Postgres did have something akin to the Python C style guide, that > > would be excellent. But all we've got is a standard tabstop of four > > spaces and the five words "Our standard format BSD style". Don't you > > think that comes across as pretty weak for a project of this size and > > significance? > > The reason it's not necessary to be very explicit about that is simple: > pg_indent. Your code *will* conform to the layout standards by the > time it's released ;-). Now it's still a good idea to make new code > look roughly like what you see there already, because if you go too > far overboard in ignoring line-length or comment layout conventions, > the code may look a bit awful when pg_indent gets done with it. > But I see no need to burden authors with any advice more detailed > than "make it look like what you see". > > Having said that, there are two or three tips worth knowing about > pg_indent's behavior, like when and how to use dashes to prevent > comment blocks from being re-flowed. But it's a short list. Agreed, and the developer's FAQ already has this: pgindent will the format code by specifying flags to your operating system's utility indent. This http://ezine.daemonnews.org/200112/single_coding_style.html";>article describes the value of a consistent coding style. pgindent is run on all source files just before each beta test period. It auto-formats all source files to make them consistent. Comment blocks that need specific line breaks should be formatted as block comments, where the comment starts as /*--. These comments will not be reformatted in any way. -- Bruce Momjian <[EMAIL PROTECTED]>http://momjian.us EnterpriseDB http://postgres.enterprisedb.com + If your life is a hard drive, Christ can be your backup. + ---(end of broadcast)--- TIP 5: don't forget to increase your free space map settings
Re: [HACKERS] minimal update
Michael Glaesemann <[EMAIL PROTECTED]> writes: > What would be the disadvantages of always doing this, i.e., just > making this part of the normal update path in the backend? (1) cycles wasted to no purpose in the vast majority of cases. (2) visibly inconsistent behavior for apps that pay attention to ctid/xmin/etc. (3) visibly inconsistent behavior for apps that have AFTER triggers. There's enough other overhead in issuing an update (network, parsing/planning/etc) that a sanely coded application should try to avoid issuing no-op updates anyway. The proposed trigger is just a band-aid IMHO. I think having it as an optional trigger is a reasonable compromise. regards, tom lane ---(end of broadcast)--- TIP 3: Have you checked our extensive FAQ? http://www.postgresql.org/docs/faq
Re: [HACKERS] A small rant about coding style for backend functions
"Brendan Jurd" <[EMAIL PROTECTED]> writes: > If Postgres did have something akin to the Python C style guide, that > would be excellent. But all we've got is a standard tabstop of four > spaces and the five words "Our standard format BSD style". Don't you > think that comes across as pretty weak for a project of this size and > significance? The reason it's not necessary to be very explicit about that is simple: pg_indent. Your code *will* conform to the layout standards by the time it's released ;-). Now it's still a good idea to make new code look roughly like what you see there already, because if you go too far overboard in ignoring line-length or comment layout conventions, the code may look a bit awful when pg_indent gets done with it. But I see no need to burden authors with any advice more detailed than "make it look like what you see". Having said that, there are two or three tips worth knowing about pg_indent's behavior, like when and how to use dashes to prevent comment blocks from being re-flowed. But it's a short list. regards, tom lane ---(end of broadcast)--- TIP 4: Have you searched our list archives? http://archives.postgresql.org
Re: [HACKERS] interval * numeric operator
Am Donnerstag, 8. November 2007 schrieb Gregory Stark: > Shouldn't the cast be implicit anyways? What does having double precision > operators buy us? Wouldn't it introduce ambiguities? Unless you use --enable-integer-datetimes, interval is stored as float internally, so historically, the selection of offered operators is correct. -- Peter Eisentraut http://developer.postgresql.org/~petere/ ---(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
Re: [HACKERS] Feature Request: inline comments
> Feature freeze was six months ago, and no this wouldn't be a > "small add" even if it was the best idea since sliced bread. +1 ---(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] interval * numeric operator
"Josh Berkus" <[EMAIL PROTECTED]> writes: > Peter Eisentraut wrote: >> There are interval * double precision operators (both ways) but none for >> interval * numeric. Adding this would make sense since interval is now >> optionally stored as fixed-point internally. Any objections to adding this >> in 8.4? > > +1 > > I've been casting to Numeric anyway. Shouldn't the cast be implicit anyways? What does having double precision operators buy us? Wouldn't it introduce ambiguities? -- Gregory Stark EnterpriseDB http://www.enterprisedb.com Ask me about EnterpriseDB's 24x7 Postgres support! ---(end of broadcast)--- TIP 2: Don't 'kill -9' the postmaster
Re: [HACKERS] Test lab
Joshua D. Drake wrote: -BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Hello, The test lab is finally starting to come to fruition. We (the community) have been donated hardware via MyYearbook and Hi5. It is my understanding that we may also have some coming from HP. Also, from Sun, and from Intel. Holdup on the Hi5 equipment is that I don't have any packing materials for it, so I still need to figure out how to freight it. And Unisys says that they can put a machine online for us too. I've talked to the folks who wrote Sun's test lab software about copying it so that we can have a way to allocate time slots. Now, if only I could spend 2 weeks in the US in a row, I could get all this together ... --Josh ---(end of broadcast)--- TIP 2: Don't 'kill -9' the postmaster
Re: [HACKERS] interval * numeric operator
Peter Eisentraut wrote: There are interval * double precision operators (both ways) but none for interval * numeric. Adding this would make sense since interval is now optionally stored as fixed-point internally. Any objections to adding this in 8.4? +1 I've been casting to Numeric anyway. --Josh ---(end of broadcast)--- TIP 6: explain analyze is your friend
Re: [HACKERS] New tzdata available
Devrim GÜNDÜZ napsal(a): Hi, ftp://elsie.nci.nih.gov/pub/tzdata2007i.tar.gz Per announcement: "...is now available; this reflects changes for Cuba and Syria circulated earlier this week on the time zone mailing list. There are no code changes, so there's no tzcode2007i; tzcood2007h remains current." I think we need some different mechanism how to deliver timezone updated. Bump version and rebuild everything when new timezone files are released is not good idea, especially in case when most unix packagers use system timezone. Zdenek ---(end of broadcast)--- TIP 3: Have you checked our extensive FAQ? http://www.postgresql.org/docs/faq
Re: [HACKERS] minimal update
On Nov 2, 2007, at 13:44 , Andrew Dunstan wrote: Ah. Good. Thanks, that's the piece I was missing. What would be the disadvantages of always doing this, i.e., just making this part of the normal update path in the backend? I'd think it should save on unnecessarily dead tuples as well. Michael Glaesemann grzm seespotcode net ---(end of broadcast)--- TIP 5: don't forget to increase your free space map settings
Re: [HACKERS] A small rant about coding style for backend functions
Gregory Stark wrote: > "Brendan Jurd" <[EMAIL PROTECTED]> writes: > > > If Postgres did have something akin to the Python C style guide, that > > would be excellent. But all we've got is a standard tabstop of four > > spaces and the five words "Our standard format BSD style". Don't you > > think that comes across as pretty weak for a project of this size and > > significance? > > So you're saying we should adopt a code standard because it looks good? We already _have_ a code standard. We're just not making it explicit. -- Alvaro Herrera Developer, http://www.PostgreSQL.org/ "Los dioses no protegen a los insensatos. Ãstos reciben protección de otros insensatos mejor dotados" (Luis Wu, Mundo Anillo) ---(end of broadcast)--- TIP 3: Have you checked our extensive FAQ? http://www.postgresql.org/docs/faq
Re: [HACKERS] A small rant about coding style for backend functions
"Brendan Jurd" <[EMAIL PROTECTED]> writes: > If Postgres did have something akin to the Python C style guide, that > would be excellent. But all we've got is a standard tabstop of four > spaces and the five words "Our standard format BSD style". Don't you > think that comes across as pretty weak for a project of this size and > significance? So you're saying we should adopt a code standard because it looks good? White space and formatting issues just aren't that big a deal. It's professional courtesy to submit a patch that follows the style of the surrounding code, but we don't even insist on that for patches. We reformat with pgindent periodically anyways. It's like a doctor's practice concerned about malpractice claims publishing a written guideline explicitly listing which articles of clothing aren't professional looking enough. -- Gregory Stark EnterpriseDB http://www.enterprisedb.com Ask me about EnterpriseDB's On-Demand Production Tuning ---(end of broadcast)--- TIP 5: don't forget to increase your free space map settings
Re: [HACKERS] Visibility map thoughts
Kevin Grittner wrote: I know this issue on this thread has come up at least one or two other times lately: http://archives.postgresql.org/pgsql-performance/2007-08/msg00113.php I know it's a largely independent issue, but your comment about the API not giving access to the index tuples echoed comments regarding what it would take to allow optimizations in this area. If we do separate the index scan and heap fetch to two executor nodes, it would handle that case as well, I think. It's not directly related to index-only scans, but returning data from an index is required for that as well. It wouldn't be a bitmap index scan anymore, BTW. -- Heikki Linnakangas EnterpriseDB http://www.enterprisedb.com ---(end of broadcast)--- TIP 7: You can help support the PostgreSQL project by donating at http://www.postgresql.org/about/donate
Re: [HACKERS] A small rant about coding style for backend functions
On Nov 8, 2007 2:49 AM, Gregory Stark <[EMAIL PROTECTED]> wrote: > > None of these points in here seem at all analogous to the important kind of > style details like what Tom was pointing out about using GETARG_* at the top > of your function to make the argument types clear. > I would love to see a Postgres style guide which includes both: things that are peculiar to the Postgres codebase like GETARG, and an actual standard on how to use whitespace, formatting and naming consistently. If Postgres did have something akin to the Python C style guide, that would be excellent. But all we've got is a standard tabstop of four spaces and the five words "Our standard format BSD style". Don't you think that comes across as pretty weak for a project of this size and significance? Cheers, BJ ---(end of broadcast)--- TIP 7: You can help support the PostgreSQL project by donating at http://www.postgresql.org/about/donate
