Re: [HACKERS] NUMERIC type benchmarks
Am Freitag, 13. April 2001 23:16 schrieben Sie: > Tom Lane wrote: > > A more significant point is that you have presented no evidence to back > > up your claim that this would be materially faster than the existing > > type. I doubt that the extra pallocs are all that expensive. (I think > > it'd be far more helpful to reimplement numeric using base-1 > > representation --- four decimal digits per int16 --- and then eliminate > > the distinction between storage format and computation format. See past > > discussions in the pghackers archives.) > > I did several tests with functions designed to sum the number 12345 a > million times. The results are as follows (Pentium II 450, Redhat 6.2): > > Postgres PL/PGSQL original numeric:14.8 seconds > Postgres PL/PGSQL modified numeric:11.0 seconds > Postgres PL/PGSQL float8: 10.7 seconds > GNU AWK:2.5 seconds > Oracle PL/SQL number: 2.0 seconds > > The modified Postgres numeric type is the original source code modified to > use a 32 digit NumericVar attribute digit buffer that eliminates > palloc()/pfree() calls when ndigits < 32. > > Surely those are performance differences worth considering... I tested that on a similar configuration (P-III 450) and got the same results. When the addition is removed from the loop and replaced with a simple assignment, the total execution time goes down to ~6.5 seconds. That means that the modified numeric is nearly twice as fast, sure worth considering that. -- === Mario Weilguni KPNQwest Austria GmbH Senior Engineer Web Solutions Nikolaiplatz 4 tel: +43-316-813824 8020 graz, austria fax: +43-316-813824-26 http://www.kpnqwest.at e-mail: [EMAIL PROTECTED] === ---(end of broadcast)--- TIP 5: Have you checked our extensive FAQ? http://www.postgresql.org/users-lounge/docs/faq.html
[HACKERS] SQL
Hi, Sorry, per OOC... Somebody could tell me where I can find documentation online about SQL2 and SQL3 (especially the last). This the SQL3 approved finally? That match is between SQL92,SQL96,SQL99 and the SQL2 and SQL3? Thanks, Sergio ---(end of broadcast)--- TIP 4: Don't 'kill -9' the postmaster
Re: [HACKERS] Re: Hand written parsers
On Fri, Apr 13, 2001 at 03:12:57AM -0400, Tom Lane wrote: > I have some interest in proposals to switch to a better parser-generator > tool than yacc ... There are tools to produce efficient top-down parsers as well. Those doing such parsers "by hand" may be interested in looking at PCCTS (http://www.polhode.com/pccts.html) or ANTLR (http://www.antlr.org/). -- Bruce Guenter <[EMAIL PROTECTED]> http://em.ca/~bruceg/ PGP signature ---(end of broadcast)--- TIP 2: you can get off all lists at once with the unregister command (send "unregister YourEmailAddressHere" to [EMAIL PROTECTED])
[HACKERS] CRN article
Folks, By now, I imagine a number of people have seen the piece on the Computer Reseller News website about Great Bridge and PostgreSQL. While I think we're all happy to see the increased visibility for PostgreSQL (especially as compared to the Oracles of the world), it's fair to say the article wasn't perfect. As Nathan Myers observed in another post, they rarely are. ;-) I thought the reporter did a good job of talking about Great Bridge's business model and how we work with resellers and third-party software developers (which after all is the focus of the magazine). Sure, there were some minor errors of fact, like the confusion over PostgreSQL's Berkeley origins, and the use of the word "licensing." But of greater concern to us, and the reason I'm writing this note, is the lack of clarity about the open source community that has built, and continues to build this software. Great Bridge is one company, one member of a large community, and a relative newcomer to the party. We employ several leading PostgreSQL developers, and give back to the project in many ways, but at the end of the day, we're still only a very small part of the larger project - which precedes us by many years, and could very easily survive us as well. We are *a* marketing channel for PostgreSQL (not *the* channel), provide services around the software, and release a QA-certified distribution (bundled with other tools and applications), but we know that it's not *our* software. It's everyone's, and I'm sorry the article didn't adequately represent that reality. Having said that, I'd ask everyone to take a deep breath, as Nathan suggested, and realize that it's still early in the adoption cycle for open source in the larger business world and the mass media. There will continue to be nuances that seem blindingly obvious to us, but slip right through the reporting and editing process in the trade press. That's ok, as long as we correct those errors, as delicately as possible ;-) We all have a shared stake in PostgreSQL being more widely used and appreciated, and how we respond to things like this will go a long way toward furthering that goal. You can all be justifiably proud of the work that's gone into PostgreSQL, leading up to the terrific 7.1 release; a big part of Great Bridge's job as a marketing organization is to make sure the world finds out about it - an ongoing job that we take very seriously. If anyone has any questions about Great Bridge's position on this kind of stuff, please feel free to email me off-list. Thanks, Ned -- Ned Lilly e: [EMAIL PROTECTED] Vice Presidentw: www.greatbridge.com Evangelism / Hacker Relationsv: 757.233.5523 Great Bridge, LLCf: 757.233. ---(end of broadcast)--- TIP 3: 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] CRN article
So, to sum up ... the article did a good job of representing Great Bridge,
did a great injustice (a slap in the face, so to say) to the PostgreSQL
community as a whole, so Great Bridge has no intention of correcting the
situation?
Just to clarify your position, of course ...
On Sun, 15 Apr 2001, Ned Lilly wrote:
> Folks,
>
> By now, I imagine a number of people have seen the piece on the
> Computer Reseller News website about Great Bridge and PostgreSQL.
> While I think we're all happy to see the increased visibility for
> PostgreSQL (especially as compared to the Oracles of the world),
> it's fair to say the article wasn't perfect. As Nathan Myers
> observed in another post, they rarely are. ;-)
>
> I thought the reporter did a good job of talking about Great
> Bridge's business model and how we work with resellers and
> third-party software developers (which after all is the focus of the
> magazine). Sure, there were some minor errors of fact, like the
> confusion over PostgreSQL's Berkeley origins, and the use of the
> word "licensing."
>
> But of greater concern to us, and the reason I'm writing this note,
> is the lack of clarity about the open source community that has
> built, and continues to build this software. Great Bridge is one
> company, one member of a large community, and a relative newcomer to
> the party. We employ several leading PostgreSQL developers, and
> give back to the project in many ways, but at the end of the day,
> we're still only a very small part of the larger project - which
> precedes us by many years, and could very easily survive us as
> well. We are *a* marketing channel for PostgreSQL (not *the*
> channel), provide services around the software, and release a
> QA-certified distribution (bundled with other tools and
> applications), but we know that it's not *our* software. It's
> everyone's, and I'm sorry the article didn't adequately represent
> that reality.
>
> Having said that, I'd ask everyone to take a deep breath, as Nathan
> suggested, and realize that it's still early in the adoption cycle
> for open source in the larger business world and the mass media.
> There will continue to be nuances that seem blindingly obvious to
> us, but slip right through the reporting and editing process in the
> trade press. That's ok, as long as we correct those errors, as
> delicately as possible ;-)
>
> We all have a shared stake in PostgreSQL being more widely used and
> appreciated, and how we respond to things like this will go a long
> way toward furthering that goal. You can all be justifiably proud
> of the work that's gone into PostgreSQL, leading up to the terrific
> 7.1 release; a big part of Great Bridge's job as a marketing
> organization is to make sure the world finds out about it - an
> ongoing job that we take very seriously.
>
> If anyone has any questions about Great Bridge's position on this
> kind of stuff, please feel free to email me off-list.
>
> Thanks,
> Ned
>
> --
>
> Ned Lilly e: [EMAIL PROTECTED]
> Vice Presidentw: www.greatbridge.com
> Evangelism / Hacker Relationsv: 757.233.5523
> Great Bridge, LLCf: 757.233.
>
>
>
> ---(end of broadcast)---
> TIP 3: 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
>
Marc G. Fournier ICQ#7615664 IRC Nick: Scrappy
Systems Administrator @ hub.org
primary: [EMAIL PROTECTED] secondary: scrappy@{freebsd|postgresql}.org
---(end of broadcast)---
TIP 2: you can get off all lists at once with the unregister command
(send "unregister YourEmailAddressHere" to [EMAIL PROTECTED])
Re: [HACKERS] Fast Forward (fwd)
On Sat, 14 Apr 2001, Nathan Myers wrote: > This is probably a good time to point out that this is the _worst_ > _possible_ response to erroneous reportage. The perception by readers > will not be that the reporter failed, but that PostgreSQL advocates > are rabid weasels who don't appreciate favorable attention, and are favorable attention?? > dangerous to write anything about. You can bet this reporter and her > editor will treat the topic very circumspectly (i.e. avoid it) in the > future. woo hoo, if that is the result, then I think Vince did us a great service, not dis-service ... > Most reporters are ignorant, most reporters are lazy, and many are > both. It's part of the job description. Getting angry about it is > like getting angry at birds for fouling their cage. Their job is to > regurgitate what they're given, and quickly. They have no time to > learn the depths, or to write coherently about it, or even to check > facts. Out of all the articles on PgSQL that I've read over the years, this one should have been shot before it hit the paper (so to say) ... it was the most blatantly inaccurate article I've ever read ... > It will be harder than the original mailings, but I urge each who > wrote to write again and apologize for attacking her. In a way, I think you are right .. I think the attack was aimed at the wrong ppl :( She obviously didn't get *any* of her information from ppl that belong *in* the Pg community, or that have any knowledge of how it works, or of its history :( ---(end of broadcast)--- TIP 3: 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] Re: 7.1 RPMs
Bruce Momjian wrote: > > Do we need to start thinking about an RPM mailing list? Seems there is > lots of traffic. IIRC, this question was asked about 6 months ago, and the answer was RPM should be discussed on PostgreSQL-Ports. On the other hand, it seems in practice most people are unaware of this, and do in fact is general or devel. Maybe if there were PostgreSQL-RPM as an alias to PostgreSQL-Ports? Or a separate list, I don't mind either way, but it's pretty clear to me that currently there is alot of misdirected traffic.. -- Karl ---(end of broadcast)--- TIP 6: Have you searched our list archives? http://www.postgresql.org/search.mpl
Re: [HACKERS] pg_dump compatibility with 7.0
At 01:08 15/04/01 -0400, Tom Lane wrote: > >SFUNC1/STYPE1/INITCOND1 in 7.0 equate to SFUNC/STYPE/INITCOND in 7.1. >There is no 7.1 equivalent to 7.0's SFUNC2/STYPE2/INITCOND2 It now outputs a warning to stderr as well as the dump file. > --- those >have to be saved/restored separately if you are dumping a 7.0 database >with intentions of restoring it to 7.0. I'm not sure I want to support 7.0->7.0 (or 7.1->7.0) in the dump for 7.1. This could get really messy in a few versions time. It's mainly to allow smoother upward conversions. >On the other hand, if you are >dumping 7.0 with an eye to restoring to 7.1, you could just as well >raise an error if those fields are nonnull. Done. It does not crash the dump, but it does write a 'warning entry' to stderr & the dump file so that subsequent a pg_restore will display a warning as well. Amended file available at: ftp://ftp.rhyme.com.au/pub/postgresql/pg_dump/pg_dump_1505_patch.gz At the moment the version compatibility changes are relatively trivial, so I'm not sure there is any value in creating multiple modules (I had thought one per version would be TWTG). Should I apply this to CVS when it's been a little more tested? Philip Warner| __---_ Albatross Consulting Pty. Ltd. |/ - \ (A.B.N. 75 008 659 498) | /(@) __---_ Tel: (+61) 0500 83 82 81 | _ \ Fax: (+61) 0500 83 82 82 | ___ | Http://www.rhyme.com.au |/ \| |---- PGP key available upon request, | / and from pgp5.ai.mit.edu:11371 |/ ---(end of broadcast)--- TIP 4: Don't 'kill -9' the postmaster
[HACKERS] Re: Fast Forward (fwd)
To top it all off, their comments are broken -- I submitted mine and it displays Marc's again (until you click on the link of course).. *sigh* they must be using MySQL. :-) -Mitch - Original Message - From: "The Hermit Hacker" <[EMAIL PROTECTED]> To: <[EMAIL PROTECTED]> Sent: Sunday, April 15, 2001 10:44 AM Subject: Re: Fast Forward (fwd) > On Sat, 14 Apr 2001, Nathan Myers wrote: > > > This is probably a good time to point out that this is the _worst_ > > _possible_ response to erroneous reportage. The perception by readers > > will not be that the reporter failed, but that PostgreSQL advocates > > are rabid weasels who don't appreciate favorable attention, and are > > favorable attention?? > > > dangerous to write anything about. You can bet this reporter and her > > editor will treat the topic very circumspectly (i.e. avoid it) in the > > future. > > woo hoo, if that is the result, then I think Vince did us a great service, > not dis-service ... > > > Most reporters are ignorant, most reporters are lazy, and many are > > both. It's part of the job description. Getting angry about it is > > like getting angry at birds for fouling their cage. Their job is to > > regurgitate what they're given, and quickly. They have no time to > > learn the depths, or to write coherently about it, or even to check > > facts. > > Out of all the articles on PgSQL that I've read over the years, this one > should have been shot before it hit the paper (so to say) ... it was the > most blatantly inaccurate article I've ever read ... > > > It will be harder than the original mailings, but I urge each who > > wrote to write again and apologize for attacking her. > > In a way, I think you are right .. I think the attack was aimed at the > wrong ppl :( She obviously didn't get *any* of her information from ppl > that belong *in* the Pg community, or that have any knowledge of how it > works, or of its history :( > > > ---(end of broadcast)--- > TIP 3: 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 > ---(end of broadcast)--- TIP 2: you can get off all lists at once with the unregister command (send "unregister YourEmailAddressHere" to [EMAIL PROTECTED])
[HACKERS] The "Current Release Docs"
The "Current Release Docs" on the PostgreSQL website still look 7.0.Xish.. Just an FYI... -Mitch ---(end of broadcast)--- TIP 5: Have you checked our extensive FAQ? http://www.postgresql.org/users-lounge/docs/faq.html
[HACKERS] Re: Fast Forward (fwd)
> *sigh* they must be using MySQL. :-) *rofl* ---(end of broadcast)--- TIP 6: Have you searched our list archives? http://www.postgresql.org/search.mpl
Re: [HACKERS] Fast Forward (fwd)
> > Here's my response to the inaccurate article cmp produced. After > chatting with Marc I decided to post it myself. > > Since I know Ned reads this list, I formally request that he also > insists PUBLICALLY that cmp correct their inaccuracies. I'm rather > disappointed (for lack of a more descriptive word) that Bruce has not > already done so. I haven't had time to read the article. Easter weekend, ya know. Not sure how corrections are made to on-line articles, but I would think the publisher would be glad to fix what is wrong. -- Bruce Momjian| http://candle.pha.pa.us [EMAIL PROTECTED] | (610) 853-3000 + If your life is a hard drive, | 830 Blythe Avenue + Christ can be your backup.| Drexel Hill, Pennsylvania 19026 ---(end of broadcast)--- TIP 2: you can get off all lists at once with the unregister command (send "unregister YourEmailAddressHere" to [EMAIL PROTECTED])
Re: [HACKERS] Fast Forward (fwd)
> > Here's my response to the inaccurate article cmp produced. After > chatting with Marc I decided to post it myself. > > Since I know Ned reads this list, I formally request that he also > insists PUBLICALLY that cmp correct their inaccuracies. I'm rather > disappointed (for lack of a more descriptive word) that Bruce has not > already done so. One more thing. This is a minor media outlet, so I don't get too worked up to fix it right away. I assume no one is there on the weekend anyway. If it was a major distributor of information, I would be more inclined to get it fixed rapidly. I did skim the article, but did not read it. When I don't recognize the publisher, I have a tendency to just ignore PostgreSQL press. -- Bruce Momjian| http://candle.pha.pa.us [EMAIL PROTECTED] | (610) 853-3000 + If your life is a hard drive, | 830 Blythe Avenue + Christ can be your backup.| Drexel Hill, Pennsylvania 19026 ---(end of broadcast)--- TIP 4: Don't 'kill -9' the postmaster
Re: [HACKERS] Fast Forward (fwd)
> > It will be harder than the original mailings, but I urge each who > > wrote to write again and apologize for attacking her. > > In a way, I think you are right .. I think the attack was aimed at the > wrong ppl :( She obviously didn't get *any* of her information from ppl > that belong *in* the Pg community, or that have any knowledge of how it > works, or of its history :( This echos my earlier observation. Many of these writers for minor publications just throw the information together. I can't be bothered to jump every time tney make a major mistake because they have not done any work on their part to get the correct story. Not that it shouldn't be fixed. I just don't get worked up over it. -- Bruce Momjian| http://candle.pha.pa.us [EMAIL PROTECTED] | (610) 853-3000 + If your life is a hard drive, | 830 Blythe Avenue + Christ can be your backup.| Drexel Hill, Pennsylvania 19026 ---(end of broadcast)--- TIP 5: Have you checked our extensive FAQ? http://www.postgresql.org/users-lounge/docs/faq.html
Re: [HACKERS] NUMERIC type benchmarks - CORRECTED
Mario Weilguni wrote: > I tested that on a similar configuration (P-III 450) and got the same > results. When the addition is removed from the loop and replaced with a > simple assignment, the total execution time goes down to ~6.5 seconds. That > means that the modified numeric is nearly twice as fast, sure worth > considering that. I am embarrassed to admit I had an undeleted overloaded function that caused me to time the wrong function. The correct numbers should be: Postgres PL/PGSQL original numeric:14.8 seconds Postgres PL/PGSQL modified numeric:14.0 seconds Postgres PL/PGSQL float8: 10.7 seconds GNU AWK:2.5 seconds Oracle PL/SQL number: 2.0 seconds This means that Tom Lane was absolutely right - for the current numeric type implementation, palloc() overhead is not a dominant concern. A serious solution needs to change the internal format to use a larger base, as Tom suggested. - Mark Butler ---(end of broadcast)--- TIP 1: subscribe and unsubscribe commands go to [EMAIL PROTECTED]
[HACKERS] Int64 (long long) Supporting Compiler Requirement Status?
There was a discussion once about using 64 bit long long compiler support to increase the size of the transaction ids to solve the wrap around problem. I understand that there is a different solution for this now. However, my question is: Are we to the point where int64's can be used in mainstream code yet, or are there supported platforms that this will not work with? And if not, when (if ever) will such capability be standardized? The reason why I ask is I would like to experiment with a variable length base-(2^32) numeric type that I hope might be accepted someday, and base-(2^32) operations need long long support to implement in a straightforward fashion. - Mark Butler ---(end of broadcast)--- TIP 3: 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] NUMERIC type benchmarks - CORRECTED
Mark Butler <[EMAIL PROTECTED]> writes: > ... The correct numbers should be: > Postgres PL/PGSQL original numeric:14.8 seconds > Postgres PL/PGSQL modified numeric:14.0 seconds > Postgres PL/PGSQL float8: 10.7 seconds > GNU AWK:2.5 seconds > Oracle PL/SQL number: 2.0 seconds > This means that Tom Lane was absolutely right - for the current numeric type > implementation, palloc() overhead is not a dominant concern. A serious > solution needs to change the internal format to use a larger base, as Tom > suggested. What do you get if you use int4 in PL/PGSQL? The above numbers look to me like the real problem may be PL/PGSQL interpretation overhead, and not the datatype at all... regards, tom lane ---(end of broadcast)--- TIP 3: 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
[HACKERS] Re: Hey guys, check this out.
At 10:59 PM 14-04-2001 -0400, Lamar Owen wrote: >http://www.crn.com/Sections/Fast_Forward/fast_forward.asp?ArticleID=25670 > >Marc will be pleased to note that the PostgreSQL project came out of the >FreeBSD project, and is Great Bridge's database. Gotta love >journalistic license. Reporter must have missed the April 1st deadline. ;) Still I must point out that the article isn't negative. And if it's read by PHB's it doesn't make a difference anyway - the general gist is: it's decent, cheap, and virtually as good as proprietary databases. So what if there are factual errors. This is mass-media we're talking about. Just point it out if it's really negative AND it's strategically appropriate to do so. By saying there's "nothing factual" does that apply to the following as well? "Great Bridge is on the forefront of the open-source movement in providing tools that are enterprisewide and capable, and what's compelling is they provide the 24x7 support" I think some of you guys are overreacting. It's almost like those FreeBSD advocates slamming Tucows or something. Maybe you guys should get some Great Bridge marketing/PR person to handle stuff like this. Cheerio, Link. ---(end of broadcast)--- TIP 2: you can get off all lists at once with the unregister command (send "unregister YourEmailAddressHere" to [EMAIL PROTECTED])
Re: [HACKERS] Fast Forward (fwd)
Bruce Momjian wrote: > Not that it shouldn't be fixed. I just don't get worked up over it. Well, in a way I regret bringing it to the attention of the community -- just in a small way. But at the same time I realized that I was not the right one at that time to craft a reply -- after all, I'm a Baptist preacher. And we tend towards the 'getting worked up' side of things. So I've learned that there are times I shouldn't post at all. Although, that's been a long hard learning experience, one that I am still, to use my wife's charitable words, 'gaining mastery of.' It should be fixed. But community members need a levelheaded response to a likely honest omission of facts. I may very well do so, tomorrow. One of the worst facets of the Linux community, for example, is its often predatoryform of 'advocacy' -- this group is more civil than that, IMHO. She likely is off for the weekend, and hasn't read any responses yet. -- Lamar Owen WGCR Internet Radio 1 Peter 4:11 ---(end of broadcast)--- TIP 4: Don't 'kill -9' the postmaster
Re: [HACKERS] Fast Forward (fwd)
On Sun, Apr 15, 2001 at 11:44:48AM -0300, The Hermit Hacker wrote: > On Sat, 14 Apr 2001, Nathan Myers wrote: > > > This is probably a good time to point out that this is the _worst_ > > _possible_ response to erroneous reportage. The perception by readers > > will not be that the reporter failed, but that PostgreSQL advocates > > are rabid weasels who don't appreciate favorable attention, and are > > favorable attention?? Yes, totally favorable. There wasn't a hint of the condescension typically accorded free software. All of the details you find so objectionable (April vs. June? "The" marketing arm vs. "a" marketing arm?) would not even be noticed by a non-cultist. > > dangerous to write anything about. You can bet this reporter and her > > editor will treat the topic very circumspectly (i.e. avoid it) in the > > future. > > woo hoo, if that is the result, then I think Vince did us a great service, > not dis-service ... False. This may have been the reporter's and the editor's first direct exposure to free software advocates. You guys came across as hate-filled religious whackos, and that reflects on all of us. > > Most reporters are ignorant, most reporters are lazy, and many are > > both. It's part of the job description. Getting angry about it is > > like getting angry at birds for fouling their cage. Their job is to > > regurgitate what they're given, and quickly. They have no time to > > learn the depths, or to write coherently about it, or even to check > > facts. > > Out of all the articles on PgSQL that I've read over the years, this one > should have been shot before it hit the paper (so to say) ... it was the > most blatantly inaccurate article I've ever read ... It had a number of minor errors, easily corrected. The next will probably talk about what a bunch of nasty cranks and lunatics PostgreSQL fans are, unless you who wrote can display a lot more finesse in your apologies. Thanks a lot, guys. > > It will be harder than the original mailings, but I urge each who > > wrote to write again and apologize for attacking her. > > In a way, I think you are right .. I think the attack was aimed at the > wrong ppl :( She obviously didn't get *any* of her information from ppl > that belong *in* the Pg community, or that have any knowledge of how it > works, or of its history :( How is this reporter going to have developed contacts within the community? She has just started. Now you've burnt her to a crisp, and she will figure the less contact with that "community" she has, the happier she'll be. Her editor will know that mentioning PG in any context will result in a raft of hate mail from cranks, and will treat press releases from our community with the scorn they have earned. Reporters are fragile creatures, and must be gently guided toward the light. They will always get facts wrong, but that matter not at all. The overall tone of the writing is the only thing that stays with their equally dim audience. That dim audience controls the budgets for technology deployment, including databases. Next time you propose a deployment on PG instead of Oracle, thank Vince et al. when it's dismissed as a crank toy. Finally, their talkback page was most probably implemented _not_ with MySQL, but with MS SQL Server. These intramural squabbles (between MySQL and PG, between Linux and BSD, between NetBSD and OpenBSD) are justifiably seen as pathetic in the outside world. Respectful attention among projects doesn't just create a better impression, it also allows you, maybe, to learn something. (MySQL is not objectively as good as PG, but those guys are doing something right, in their presentation, that some of us could learn from.) Nathan Myers [EMAIL PROTECTED] ---(end of broadcast)--- TIP 1: subscribe and unsubscribe commands go to [EMAIL PROTECTED]
Re: [HACKERS] Re: Hey guys, check this out.
On Mon, 16 Apr 2001, Lincoln Yeoh wrote: > Maybe you guys should get some Great Bridge marketing/PR person to handle > stuff like this. After reading Ned's comments I figured that's how it got that way in the first place. But that's just speculation. Vince. -- == Vince Vielhaber -- KA8CSHemail: [EMAIL PROTECTED]http://www.pop4.net 56K Nationwide Dialup from $16.00/mo at Pop4 Networking Online Campground Directoryhttp://www.camping-usa.com Online Giftshop Superstorehttp://www.cloudninegifts.com == ---(end of broadcast)--- TIP 6: Have you searched our list archives? http://www.postgresql.org/search.mpl
Re: [HACKERS] Fast Forward (fwd)
> > Here's my response to the inaccurate article cmp produced. After > chatting with Marc I decided to post it myself. > > Since I know Ned reads this list, I formally request that he also > insists PUBLICALLY that cmp correct their inaccuracies. I'm rather > disappointed (for lack of a more descriptive word) that Bruce has not > already done so. OK, I read the article. Seems there are two major mistakes. First, they equate Great Bridge with PostgreSQL, and second, they don't know the history of PostgreSQL. If they fixed those two mistakes, the article would be OK. Seems like they have already been contacted and hopefully they will correct this. (Not sure how they do that.) In reading the article, I have to ask myself, "How upset would I be if they had equated PostgreSQL, Inc or another company with PostgreSQL?" Well, I certainly wouldn't like it, and would try to get it corrected. However, I wouldn't consider it a major problem. The press makes mistakes like this all the time, and this press outlet is just too small to worry about. -- Bruce Momjian| http://candle.pha.pa.us [EMAIL PROTECTED] | (610) 853-3000 + If your life is a hard drive, | 830 Blythe Avenue + Christ can be your backup.| Drexel Hill, Pennsylvania 19026 ---(end of broadcast)--- TIP 6: Have you searched our list archives? http://www.postgresql.org/search.mpl
Re: [HACKERS] Fast Forward (fwd)
the thing that pissed me off the most, and set me off, was the totally
blatant errors ... we've had other articles written, with a GB slant to
them, that didn't get my feathers in a ruffle ... the fact that they
*talked* with GB, got quotes from them and some of their partners, and
*still* got the facts wrong, is what got me heated ...
On Sun, 15 Apr 2001, Bruce Momjian wrote:
> >
> > Here's my response to the inaccurate article cmp produced. After
> > chatting with Marc I decided to post it myself.
> >
> > Since I know Ned reads this list, I formally request that he also
> > insists PUBLICALLY that cmp correct their inaccuracies. I'm rather
> > disappointed (for lack of a more descriptive word) that Bruce has not
> > already done so.
>
> OK, I read the article. Seems there are two major mistakes. First,
> they equate Great Bridge with PostgreSQL, and second, they don't know
> the history of PostgreSQL.
>
> If they fixed those two mistakes, the article would be OK. Seems like
> they have already been contacted and hopefully they will correct this.
> (Not sure how they do that.)
>
> In reading the article, I have to ask myself, "How upset would I be if
> they had equated PostgreSQL, Inc or another company with PostgreSQL?"
> Well, I certainly wouldn't like it, and would try to get it corrected.
> However, I wouldn't consider it a major problem. The press makes
> mistakes like this all the time, and this press outlet is just too small
> to worry about.
>
> --
> Bruce Momjian| http://candle.pha.pa.us
> [EMAIL PROTECTED] | (610) 853-3000
> + If your life is a hard drive, | 830 Blythe Avenue
> + Christ can be your backup.| Drexel Hill, Pennsylvania 19026
>
> ---(end of broadcast)---
> TIP 6: Have you searched our list archives?
>
> http://www.postgresql.org/search.mpl
>
Marc G. Fournier ICQ#7615664 IRC Nick: Scrappy
Systems Administrator @ hub.org
primary: [EMAIL PROTECTED] secondary: scrappy@{freebsd|postgresql}.org
---(end of broadcast)---
TIP 5: Have you checked our extensive FAQ?
http://www.postgresql.org/users-lounge/docs/faq.html
Re: [HACKERS] Fast Forward (fwd)
I wanted to comment on how we handled this article. Seems the author did not understand the company/open-source relationship. This is not a huge surprise. I have to explain it to my friends and relatives all the time. Now, our way of dealing with users who ask questions is to gently lead them to the answer. In this case, we have insulted the author. Hard to see how our users get gentle treatment while authors get insulted. Now, you can say that press people have to live up to a higher standard, and therefore deserve to be insulted when they get things wrong. If that is people's opinion, I can't argue with that. However, consider how many press people think Linux is developed by Red Hat. I bet there's a lot. The author didn't get the Berkely/FreeBSD/PostgreSQL relationship right either. Seems the author has a "relationship" problem. :-) -- Bruce Momjian| http://candle.pha.pa.us [EMAIL PROTECTED] | (610) 853-3000 + If your life is a hard drive, | 830 Blythe Avenue + Christ can be your backup.| Drexel Hill, Pennsylvania 19026 ---(end of broadcast)--- TIP 6: Have you searched our list archives? http://www.postgresql.org/search.mpl
Re: [HACKERS] Fast Forward (fwd)
> You can tell people why they shouldn't feel a certain way, but > preventing them from expressing their feelings is usually a bad thing, > unless their expression is hurting other people. (Hurting my feelings > is OK.) > > I usually sit back until everyone's cards/feelings are on the table, and > then decide if my saying anything will help or hurt. Oh, one more thing. I jump right into discussions if I can find a joke in the situation. :-) -- Bruce Momjian| http://candle.pha.pa.us [EMAIL PROTECTED] | (610) 853-3000 + If your life is a hard drive, | 830 Blythe Avenue + Christ can be your backup.| Drexel Hill, Pennsylvania 19026 ---(end of broadcast)--- TIP 3: 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] Re: Hey guys, check this out.
Vince Vielhaber <[EMAIL PROTECTED]> writes: > On Mon, 16 Apr 2001, Lincoln Yeoh wrote: >> Maybe you guys should get some Great Bridge marketing/PR person to handle >> stuff like this. > After reading Ned's comments I figured that's how it got that way in > the first place. But that's just speculation. It's pretty obvious that CRN's article was written after talking to a Great Bridge marketing or PR person (and no one else :-(). GB *is* engaged in trying to attract positive press attention to PostgreSQL (and itself of course); I hope no one is bothered by that activity per se. Now without having a transcript of that conversation, it's difficult to know whether the errors in the article should be blamed more on the CRN reporter or more on the GB person. I'd tend to blame the reporter, but you might well wish to discount that as the biased view of a GB employee. I will say that all the GB people I talk to understand the difference between GB and the Postgres open-source community --- but this reporter evidently does not. By and large, I agree with Nathan Myers' comments. We can either see this as a chance to educate that reporter about what open source is all about, or we can flame her and turn her off open source completely. Let's try to take the high road. regards, tom lane ---(end of broadcast)--- TIP 1: subscribe and unsubscribe commands go to [EMAIL PROTECTED]
Re: [HACKERS] Re: Hey guys, check this out.
On Sun, Apr 15, 2001 at 10:05:46PM -0400, Vince Vielhaber wrote: > On Mon, 16 Apr 2001, Lincoln Yeoh wrote: > > > Maybe you guys should get some Great Bridge marketing/PR person to handle > > stuff like this. > > After reading Ned's comments I figured that's how it got that way in > the first place. But that's just speculation. You probably figured wrong. All those publications have editors who generally feel they're not doing their job if they don't introduce errors, usually without even talking to the reporter. That's probably how the "FreeBSD" reference got in there: somebody saw "Berkeley" and decided "FreeBSD" would look more "techie". It's stupid, but nothng to excoriate the reporter about. Sam Williams's articles read completely differently according to who publishes them. Typically the Linux magazines print what he writes, and thereby get it mostly right, but the finance magazines mangle them to total nonsense. Nathan Myers [EMAIL PROTECTED] ---(end of broadcast)--- TIP 1: subscribe and unsubscribe commands go to [EMAIL PROTECTED]
[HACKERS] Re: [PATCHES] Patch for PostgreSQL 7.0.3 to compile on Tru64 UNIX v5.0A with Compaq C T6.4-212 (dtk)
OK, looks like we have a Tru64 problem with 7.1 too. Can you tell us how to get a NAN value. Zero is not it. I see the following mentions of NAN in the code. Does NAN exist in one of your /usr/include files? include/port/qnx4.h:18:#ifndef NAN include/port/qnx4.h:24:#defineNAN (*(const double *) __nan) include/port/qnx4.h:25:#endif/* NAN */ include/port/solaris.h:43:#ifndef NAN include/port/solaris.h:51:#define NAN \ include/port/solaris.h:58:#define NAN (0.0/0.0) include/port/solaris.h:62:#endif /* not NAN */ include/utils/timestamp.h:64:#ifdef NAN include/utils/timestamp.h:65:#define DT_INVALID (NAN) include/utils/timestamp.h:80:#ifdef NAN include/utils/timestamp.h:104:#ifdef NAN backend/port/qnx4/isnan.c:22: return !memcmp(&dsrc, &NAN, sizeof(double)); backend/utils/adt/float.c:106:#ifndef NAN backend/utils/adt/float.c:107:#define NAN (0.0/0.0) backend/utils/adt/float.c:251: val = NAN; backend/utils/adt/numeric.c:45:#ifndef NAN backend/utils/adt/numeric.c:46:#define NAN (0.0/0.0) backend/utils/adt/numeric.c:1718: PG_RETURN_FLOAT8(NAN); backend/utils/adt/numeric.c:1763: PG_RETURN_FLOAT4((float4) NAN); backend/utils/adt/numeric.c:2269: var->sign = NUMERIC_POS;/* anything but NAN... */ > It _doesn't_ compile on Tru64: > gmake -C adt SUBSYS.o > gmake[4]: Entering directory `/usr/users/dcarmich/postgresql-7.1/src/ > backend/utils/adt' > cc -std -O4 -Olimit 2000 -I../../../../src/include -c -o float.o float.c > cc: Error: float.c, line 251: In this statement, the libraries on this > platform do not yet support compile-time evaluation of the constant > expression "0.0/0.0". (constfoldns) > val = NAN; > --^ > gmake[4]: *** [float.o] Error 1 > gmake[4]: Leaving directory `/usr/users/dcarmich/postgresql-7.1/src/backend > /utils/adt' > gmake[3]: *** [adt-recursive] Error 2 > gmake[3]: Leaving directory `/usr/users/dcarmich/postgresql-7.1/src/backend > /utils' > gmake[2]: *** [utils-recursive] Error 2 > gmake[2]: Leaving directory `/usr/users/dcarmich/postgresql-7.1/src/ > backend' > gmake[1]: *** [all] Error 2 > gmake[1]: Leaving directory `/usr/users/dcarmich/postgresql-7.1/src' > gmake: *** [all] Error 2 > > (Sorry about the quoting, don't know how to remove it in VMS EDT.) > > > > >Please try 7.1. It should work fine. > > > >> > >> POSTGRESQL BUG REPORT TEMPLATE > >> > >> > >> > >> Your name : Douglas Carmichael > >> Your email address : [EMAIL PROTECTED] > >> > >> > >> System Configuration > >> - > >> Architecture (example: Intel Pentium): DEC/Compaq Alpha > >> > >> Operating System (example: Linux 2.0.26 ELF) : Compaq Tru64 UNIX v5.0A rev >1094 > >> > >> PostgreSQL version (example: PostgreSQL-7.0): PostgreSQL-7.0.3 > >> > >> Compiler used (example: gcc 2.8.0) : Compaq C T6.4-212 (dtk) > >> > >> > >> Please enter a FULL description of your problem: > >> > >> > >> I have patches to src/backend/utils/adt/float.c and > >> src/backend/utils/adt/numeric.c to get PostgreSQL 7.0.3 to compile on Tru64 > >> v5.0A with Compaq C T6.4-212 (dtk). > >> > >> Please describe a way to repeat the problem. Please try to provide a > >> concise reproducible example, if at all possible: > >> -- > >> > >> > >> N/A > >> > >> > >> If you know how this problem might be fixed, list the solution below: > >> - > >> > >> > >> diff -cr postgresql-7.0.3_old/src/backend/utils/adt/float.c >postgresql-7.0.3/src/backend/utils/adt/float.c > >> *** postgresql-7.0.3_old/src/backend/utils/adt/float.c Wed Apr 12 12:15:49 >2000 > >> --- postgresql-7.0.3/src/backend/utils/adt/float.c Fri Apr 13 22:13:10 2001 > >> *** > >> *** 68,74 > >> #include "utils/builtins.h" > >> > >> #ifndef NAN > >> ! #define NAN (0.0/0.0) > >> #endif > >> > >> #ifndef SHRT_MAX > >> --- 68,74 > >> #include "utils/builtins.h" > >> > >> #ifndef NAN > >> ! #define NAN 0 > >> #endif > >> > >> #ifndef SHRT_MAX > >> diff -cr postgresql-7.0.3_old/src/backend/utils/adt/numeric.c >postgresql-7.0.3/src/backend/utils/adt/numeric.c > >> *** postgresql-7.0.3_old/src/backend/utils/adt/numeric.c Wed Apr 12 12:15:50 >2000 > >> --- postgresql-7.0.3/src/backend/utils/adt/numeric.c Fri Apr 13 22:15:55 >2001 > >> *** > >> *** 41,47 > >> #endif > >> > >> #ifndef NAN > >> ! #define NAN (0.
[HACKERS] Re: [PATCHES] Patch for PostgreSQL 7.0.3 to compile on Tru64 UNIX v5.0A with Compaq C T6.4-212 (dtk)
> OK, looks like we have a Tru64 problem with 7.1 too. Can you tell us > how to get a NAN value. Zero is not it. I see the following mentions > of NAN in the code. Does NAN exist in one of your /usr/include files? We had at least three reports of successful compilation on Tru64 4.0[dg] and 5.0. So perhaps there is something else going on, or some other optional packages in an include path? - Thomas ---(end of broadcast)--- TIP 1: subscribe and unsubscribe commands go to [EMAIL PROTECTED]
[HACKERS] Re: How to do the modular test
>What I would like to know is, if I have changed some ot the modules, > how can I use GNU gdb to debug the modified codes? You can run the backend directly from gdb: $ gdb postgres (set breakpoint) > b (tell gdb to begin) > run -D (enter query at prompt) > select xyz from abc... (will run until it hits the breakpoint(s)) - Thomas ---(end of broadcast)--- TIP 2: you can get off all lists at once with the unregister command (send "unregister YourEmailAddressHere" to [EMAIL PROTECTED])
[HACKERS] Re: [PATCHES] Patch for PostgreSQL 7.0.3 to compile on Tru64 UNIX v5.0A with Compaq C T6.4-212 (dtk)
No, those don't do it. We need an actual NaN value. These are just flags, I think. > There are two things I found from fp_class.h, FP_SNAN (a signaling NaN), > and FP_QNAN (a quiet NaN). Don't know which you want: > alphapc.ourservers.net> grep FP_SNAN /usr/include/* > /usr/include/fp_class.h:#define FP_SNAN 0 > alphapc.ourservers.net> grep FP_QNAN /usr/include/* > /usr/include/fp_class.h:#define FP_QNAN 1 > > >> There is an isnan() function on v5.0a. > >> I'll be sending you the manpage. > > > >The problem is that we have to assign NAN to variables sometimes. That > >is why were were doing 0.0/0.0, to generate an NAN that could be used > >later in the code. > > > >I understand your compiler is saying it can't compute that at compile > >time. Maybe a computation that is preformed to set the value somehow. > > > >> > >> > > >> >OK, looks like we have a Tru64 problem with 7.1 too. Can you tell us > >> >how to get a NAN value. Zero is not it. I see the following mentions > >> >of NAN in the code. Does NAN exist in one of your /usr/include files? > >> > > >> > > >> > > >> >include/port/qnx4.h:18:#ifndef NAN > >> >include/port/qnx4.h:24:#define > NAN (*(const double *) __nan) > >> >include/port/qnx4.h:25:#endif/* NAN */ > >> >include/port/solaris.h:43:#ifndef NAN > >> >include/port/solaris.h:51:#define NAN \ > >> >include/port/solaris.h:58:#define NAN (0.0/0.0) > >> >include/port/solaris.h:62:#endif /* not NAN */ > >> >include/utils/timestamp.h:64:#ifdef NAN > >> >include/utils/timestamp.h:65:#define DT_INVALID (NAN) > >> >include/utils/timestamp.h:80:#ifdef NAN > >> >include/utils/timestamp.h:104:#ifdef NAN > >> >backend/port/qnx4/isnan.c:22: return !memcmp(&dsrc, &NAN, sizeof(double)); > >> >backend/utils/adt/float.c:106:#ifndef NAN > >> >backend/utils/adt/float.c:107:#define NAN (0.0/0.0) > >> >backend/utils/adt/float.c:251: val = NAN; > >> >backend/utils/adt/numeric.c:45:#ifndef NAN > >> >backend/utils/adt/numeric.c:46:#define NAN (0.0/0.0) > >> >backend/utils/adt/numeric.c:1718: PG_RETURN_FLOAT8(NAN); > >> >backend/utils/adt/numeric.c:1763: PG_RETURN_FLOAT4((float4) NAN); > >> >backend/utils/adt/numeric.c:2269: var->sign = NUMERIC_POS;/* >anything but NAN... */ > >> > > >> > > >> > > >> >> It _doesn't_ compile on Tru64: > >> >> gmake -C adt SUBSYS.o > >> >> gmake[4]: Entering directory `/usr/users/dcarmich/postgresql-7.1/src/ > >> >> backend/utils/adt' > >> >> cc -std -O4 -Olimit 2000 -I../../../../src/include -c -o float.o float.c > >> >> cc: Error: float.c, line 251: In this statement, the libraries on this > >> >> platform do not yet support compile-time evaluation of the constant > >> >> expression "0.0/0.0". (constfoldns) > >> >> val = NAN; > >> >> --^ > >> >> gmake[4]: *** [float.o] Error 1 > >> >> gmake[4]: Leaving directory `/usr/users/dcarmich/postgresql-7.1/src/backend > >> >> /utils/adt' > >> >> gmake[3]: *** [adt-recursive] Error 2 > >> >> gmake[3]: Leaving directory `/usr/users/dcarmich/postgresql-7.1/src/backend > >> >> /utils' > >> >> gmake[2]: *** [utils-recursive] Error 2 > >> >> gmake[2]: Leaving directory `/usr/users/dcarmich/postgresql-7.1/src/ > >> >> backend' > >> >> gmake[1]: *** [all] Error 2 > >> >> gmake[1]: Leaving directory `/usr/users/dcarmich/postgresql-7.1/src' > >> >> gmake: *** [all] Error 2 > >> >> > >> >> (Sorry about the quoting, don't know how to remove it in VMS EDT.) > >> >> > >> >> > > >> >> >Please try 7.1. It should work fine. > >> >> > > >> >> >> > >> >> >> POSTGRESQL BUG REPORT TEMPLATE > >> >> >> > >> >> >> > >> >> >> > >> >> >> Your name: Douglas Carmichael > >> >> >> Your email address : [EMAIL PROTECTED] > >> >> >> > >> >> >> > >> >> >> System Configuration > >> >> >> - > >> >> >> Architecture (example: Intel Pentium) : DEC/Compaq Alpha > >> >> >> > >> >> >> Operating System (example: Linux 2.0.26 ELF) : Compaq Tru64 UNIX >v5.0A rev 1094 > >> >> >> > >> >> >> PostgreSQL version (example: PostgreSQL-7.0): PostgreSQL-7.0.3 > >> >> >> > >> >> >> Compiler used (example: gcc 2.8.0): Compaq C T6.4-212 >(dtk) > >> >> >> > >> >> >> > >> >> >> Please enter a FULL description of your problem: > >> >> >> > >> >> >> > >> >> >> I have patches to src/backend/utils/adt/float.c and > >> >> >> src/backend/utils/adt/numeric.c to get PostgreSQL 7.0.3 to compile on Tru64 > >> >> >> v5.0A with Compaq C T6.4-212 (dtk). > >> >> >> > >> >> >> Please describe a way to repeat the problem. Please
Re: [HACKERS] Int64 (long long) Supporting Compiler Requirement Status?
Mark Butler <[EMAIL PROTECTED]> writes: > However, my question is: Are we to the point where int64's can be used in > mainstream code yet, or are there supported platforms that this will not work > with? And if not, when (if ever) will such capability be standardized? I don't foresee ever being willing to *require* int64 support. It'll always be optional. > The reason why I ask is I would like to experiment with a variable length > base-(2^32) numeric type that I hope might be accepted someday, and > base-(2^32) operations need long long support to implement in a > straightforward fashion. I really doubt that base 2^32 would be enough faster than base 1 to be worth taking any portability risks for. regards, tom lane ---(end of broadcast)--- TIP 4: Don't 'kill -9' the postmaster
