Sun's PostgreSQL contribution?

http://blogs.mysql.com/kaj/sun-acquires-mysql.html/

What does this mean for Sun's support of Postgres?

--

Russ.

Russ Brown wrote:
> http://blogs.mysql.com/kaj/sun-acquires-mysql.html/
>
> What does this mean for Sun's support of Postgres?
>

Does it matter? :) I am sure OmniTI and Command Prompt will be
happy to help any disgruntled customer :)

Sincerely,

Joshua D. Drake

Joshua Drake shaped the electrons to say:

>
> Russ Brown wrote:
> > http://blogs.mysql.com/kaj/sun-acquires-mysql.html/
> >
> > What does this mean for Sun's support of Postgres?
> >
>
> Does it matter? :) I am sure OmniTI and Command Prompt will be
> happy to help any disgruntled customer :)

Well, in the past year or so Sun seemed to have been moving toward support of PostgreSQL and there was considerable traffic on Great And Subtle Things Beyond My Ken [Jignish Shah, I think, might be the name of the Sun engineer who was working on some issues]. If they own MySQL support for PostgreSQL might be reduced, and perhaps Oracle ? Hard to tell from the blog report. Sun might have some specific use for some aspect of MySQL, or maybe it is part of something bigger. But potentially it could freeze PostgreSQL out of more Sun-centric shops. {locally we use Linux mostly, some Sun, but used to be much more Sun oriented; personally from a Sun background and have a faint fondness for their servers}. I doubt that any entity other than Sun can provide software fixes for issues in Sun kernels that might improve PostgreSQL's performance.

My $0.04 worth (inflation)

Greg Williamson
Senior DBA
GlobeXplorer LLC, a DigitalGlobe company

Confidentiality Notice: This e-mail message, including any attachments, is for the sole use of the intended recipient(s) and may contain confidential and privileged information and must be protected in accordance with those provisions. Any unauthorized review, use, disclosure or distribution is prohibited. If you are not the intended recipient, please contact the sender by reply e-mail and destroy all copies of the original message.

(My corporate masters made me say this.)

<*may* not *does*, and how the heck could anyone destroy all copies of the original ?!? That's a hoot! my Corporate Masters did not make me say this, too much beer did! >

Russ Brown wrote:
> http://blogs.mysql.com/kaj/sun-acquires-mysql.html/
>
> What does this mean for Sun's support of Postgres?
>

Speaking from pure opinion here :)

Oracle for example is buying out the little techs that MySQL relies on -
BDB and InnoDB.

The main company, MySQL AB was all that was left to effectively give
them control of MySQL.

PostgreSQL obviously doesn't have this risk - No one company holds that
much power, and even the -core team is split between the various
supporting companies around PostgreSQL.

Sun wants to support both.
If you wanted to ensure MySQL continued as a company, and you had the
money, its not a bad idea really.

Sun buys MySQL AB, ensures it continues.

I don't see Sun's support of PostgreSQL going away though.
I'm sure they have various support contracts out, not to mention various
employees working on it.

Sun can still contribute equally to PostgreSQL, and it can still make
just as much money on PostgreSQL as it does on MySQL.

Though PostgreSQL I imagine is cheaper as the community does more of the
work, they can just provide the additional support. MySQL they have
additional costs as they do more of the development.

I'm actually very curious now that Sun owns it, will they change how the
community contributes to the database?

I personally prefer the PostgreSQL community, joining and contributing
to the community I've found to be easier.

Then there is - How will Oracle feel about Solaris now?
Before Sun just supported the competition, it didn't "own" a direct
competitor.

Weslee

On Jan 16, 2008 7:19 AM, Russ Brown <pickscrape(at)gmail(dot)com> wrote:
> http://blogs.mysql.com/kaj/sun-acquires-mysql.html/
>
> What does this mean for Sun's support of Postgres?

I don't see why it should change really, they kind of swim in different waters.

What I do think is interesting is that Sun might actually more fully
open up MySQL than it has been so far. I.e relax the viral nature of
the connect libs. Go back to LGPL licensing on them. Stop trying to
collect licensing fees on an open source database. Make the money on
consulting instead.

It would also be nice to see them do something to streamline the whole
2^n licensing / build model they currently struggle under. Taking a
year to fix a fairly innocuous packaging bug, then reintroducing that
bug, then squashing it again is not good. It would be nice to see
them streamline the development process. Having 4 or 5 active
development branches is too chaotic.

How much does Sun currently contribute to the project? Do they have
designated coders?
--
View this message in context: http://www.nabble.com/Sun-acquires-MySQL-tp14881966p14884994.html
Sent from the PostgreSQL - general mailing list archive at Nabble.com.

Scott Marlowe wrote:
> On Jan 16, 2008 7:19 AM, Russ Brown <pickscrape(at)gmail(dot)com> wrote:
>> http://blogs.mysql.com/kaj/sun-acquires-mysql.html/
>>
>> What does this mean for Sun's support of Postgres?
>
> I don't see why it should change really, they kind of swim in different waters.
>
> What I do think is interesting is that Sun might actually more fully
> open up MySQL than it has been so far. I.e relax the viral nature of
> the connect libs.

To my knowledge that "argument" is long gone, over and no longer
relevant. What they do is hold their security fixes back and have
official packages etc..

Sincerely,

Joshua D. Drake

dvanatta wrote:
> How much does Sun currently contribute to the project? Do they have
> designated coders?

They employ a core member who is not a hacker.
They provide some machines etc..

Sincerely,

Joshua D. Drake

Joshua D. Drake wrote:
> dvanatta wrote:
>> How much does Sun currently contribute to the project? Do they have
>> designated coders?
>
> They employ a core member who is not a hacker.
> They provide some machines etc..

They contributed a DTrace patch and the Sun hackers can be seen from
time to time. They're not just marketing ...

--
Alvaro Herrera http://www.CommandPrompt.com/
The PostgreSQL Company - Command Prompt, Inc.

Alvaro Herrera wrote:
> Joshua D. Drake wrote:
>> dvanatta wrote:
>>> How much does Sun currently contribute to the project? Do they have
>>> designated coders?
>> They employ a core member who is not a hacker.
>> They provide some machines etc..
>
> They contributed a DTrace patch and the Sun hackers can be seen from
> time to time. They're not just marketing ...

I didn't mean to imply that. I took his question as does Sun have
regularly contributing hackers like yourself of AndrewD.

Sincerely,

Joshua D. Drake

If MySQL goes the way of Java, maybe there isn't too much to worry
about.

-----Original Message-----
From: pgsql-general-owner(at)postgresql(dot)org
[mailto:pgsql-general-owner(at)postgresql(dot)org] On Behalf Of Weslee Bilodeau
Sent: Wednesday, January 16, 2008 10:56 AM
To: Russ Brown
Cc: pgsql-general(at)postgresql(dot)org
Subject: Re: [GENERAL] Sun acquires MySQL

Russ Brown wrote:
> http://blogs.mysql.com/kaj/sun-acquires-mysql.html/
>
> What does this mean for Sun's support of Postgres?
>

Speaking from pure opinion here :)

Oracle for example is buying out the little techs that MySQL relies on -
BDB and InnoDB.

The main company, MySQL AB was all that was left to effectively give
them control of MySQL.

PostgreSQL obviously doesn't have this risk - No one company holds that
much power, and even the -core team is split between the various
supporting companies around PostgreSQL.

Sun wants to support both.
If you wanted to ensure MySQL continued as a company, and you had the
money, its not a bad idea really.

Sun buys MySQL AB, ensures it continues.

I don't see Sun's support of PostgreSQL going away though.
I'm sure they have various support contracts out, not to mention various
employees working on it.

Sun can still contribute equally to PostgreSQL, and it can still make
just as much money on PostgreSQL as it does on MySQL.

Though PostgreSQL I imagine is cheaper as the community does more of the
work, they can just provide the additional support. MySQL they have
additional costs as they do more of the development.

I'm actually very curious now that Sun owns it, will they change how the
community contributes to the database?

I personally prefer the PostgreSQL community, joining and contributing
to the community I've found to be easier.

Then there is - How will Oracle feel about Solaris now?
Before Sun just supported the competition, it didn't "own" a direct
competitor.

Weslee

---------------------------(end of broadcast)---------------------------
TIP 5: don't forget to increase your free space map settings

> The main company, MySQL AB was all that was left to effectively give
> them control of MySQL.
>
> PostgreSQL obviously doesn't have this risk - No one company holds that
> much power, and even the -core team is split between the various
> supporting companies around PostgreSQL.
>

Is this up to date?

http://www.postgresql.org/community/contributors/

I'm asking because I was always told EnterpriseDB employs now 5 out of 7
core committers.

Thanks for the clarification.

Dirk

--
Phone: + 1 (650) 215 3459
Web: http://www.riehle.org

2 out of 7 - which would be Bruce & I.

Regards, Dave

On 1/16/08, Dirk Riehle <dirk(at)riehle(dot)org> wrote:
>
> > The main company, MySQL AB was all that was left to effectively give
> > them control of MySQL.
> >
> > PostgreSQL obviously doesn't have this risk - No one company holds that
> > much power, and even the -core team is split between the various
> > supporting companies around PostgreSQL.
> >
>
> Is this up to date?
>
> http://www.postgresql.org/community/contributors/
>
> I'm asking because I was always told EnterpriseDB employs now 5 out of 7
> core committers.
>
> Thanks for the clarification.
>
> Dirk
>
> --
> Phone: + 1 (650) 215 3459
> Web: http://www.riehle.org
>
>
>
> ---------------------------(end of broadcast)---------------------------
> TIP 3: Have you checked our extensive FAQ?
>
> http://www.postgresql.org/docs/faq
>

--
Sent from my mobile device

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

On Wed, 16 Jan 2008 10:25:45 -0800
Dirk Riehle <dirk(at)riehle(dot)org> wrote:

>
> > The main company, MySQL AB was all that was left to effectively give
> > them control of MySQL.
> >
> > PostgreSQL obviously doesn't have this risk - No one company holds
> > that much power, and even the -core team is split between the
> > various supporting companies around PostgreSQL.
> >
>
> Is this up to date?
>
> http://www.postgresql.org/community/contributors/
>
> I'm asking because I was always told EnterpriseDB employs now 5 out
> of 7 core committers.

What? They do employ more contributors than that (oh and just because
they are core doesn't mean they have commit rights).

They employ Dave Page and Bruce Momjian who are core members.
They also employ Greg Stark and Heikki are very fairly visible
contributors.

Sincerely,

Joshua D. Drake

- --
The PostgreSQL Company: Since 1997, http://www.commandprompt.com/
Sales/Support: +1.503.667.4564 24x7/Emergency: +1.800.492.2240
Donate to the PostgreSQL Project: http://www.postgresql.org/about/donate
SELECT 'Training', 'Consulting' FROM vendor WHERE name = 'CMD'

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.6 (GNU/Linux)

iD8DBQFHjlBIATb/zqfZUUQRAl1xAJ9S/rm4ex4lC8xTXft5Wm1/qVjg2gCdG4s8
rT/NXbJ2Mad+AMOSNAiQ674=
=FlKG
-----END PGP SIGNATURE-----

What's up with 3 of the 7 being from Pennsylvania? What's the connection?

Dave Page-3 wrote:
>
> 2 out of 7 - which would be Bruce & I.
>
> ---------------------------(end of broadcast)---------------------------
> TIP 1: if posting/reading through Usenet, please send an appropriate
> subscribe-nomail command to majordomo(at)postgresql(dot)org so that your
> message can get through to the mailing list cleanly
>
>

--
View this message in context: http://www.nabble.com/Sun-acquires-MySQL-tp14881966p14895300.html
Sent from the PostgreSQL - general mailing list archive at Nabble.com.

In response to dvanatta <dvanatta(at)yahoo(dot)com>:

>
> What's up with 3 of the 7 being from Pennsylvania? What's the connection?

Well, as everyone knows, Pennsylvania is a haven for brilliant
people. In fact, simply living in Pennsylvania makes you smarter.

--
Bill Moran
http://www.potentialtech.com

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

On Wed, 16 Jan 2008 13:23:35 -0800 (PST)
dvanatta <dvanatta(at)yahoo(dot)com> wrote:

>
> What's up with 3 of the 7 being from Pennsylvania? What's the
> connection?

Its the closest the cult of the elephant will get to jersey.

Joshua D. Drake

- --
The PostgreSQL Company: Since 1997, http://www.commandprompt.com/
Sales/Support: +1.503.667.4564 24x7/Emergency: +1.800.492.2240
Donate to the PostgreSQL Project: http://www.postgresql.org/about/donate
SELECT 'Training', 'Consulting' FROM vendor WHERE name = 'CMD'

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.6 (GNU/Linux)

iD8DBQFHjneZATb/zqfZUUQRAsjKAKCj3xpZ8NBEvMYKmmDJdiu/6Y50PQCeI2fr
w+d0U+qn8mmvl2ylK2LeI0Q=
=nCyQ
-----END PGP SIGNATURE-----

> Russ Brown wrote:
> > http://blogs.mysql.com/kaj/sun-acquires-mysql.html/
> >
> > What does this mean for Sun's support of Postgres?
> >

So why not go directly to the "source", Sun itself, and ask them?

Someone like Bruce should just knock on the door and ask.

Then you can evaluate the answer. Either a lie, the truth, or somewhere
in-between, and the answer may only have a certain "shelf-life", for what is
true today in the tech industry is false later.

..Otto

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

On Wed, 16 Jan 2008 16:29:01 -0500
Bill Moran <wmoran(at)potentialtech(dot)com> wrote:

> In response to dvanatta <dvanatta(at)yahoo(dot)com>:
>
> >
> > What's up with 3 of the 7 being from Pennsylvania? What's the
> > connection?
>
> Well, as everyone knows, Pennsylvania is a haven for brilliant
> people. In fact, simply living in Pennsylvania makes you smarter.

Then why did Ben Frankly attach a key to a kite in the middle of a
thunderstorm?

Joshua D. Drake

- --
The PostgreSQL Company: Since 1997, http://www.commandprompt.com/
Sales/Support: +1.503.667.4564 24x7/Emergency: +1.800.492.2240
Donate to the PostgreSQL Project: http://www.postgresql.org/about/donate
SELECT 'Training', 'Consulting' FROM vendor WHERE name = 'CMD'

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.6 (GNU/Linux)

iD8DBQFHjnlTATb/zqfZUUQRAt2HAJ4xJCGVrGnD9ydhSKkg8twAvZaM/QCfUJ7v
VDgpjoFCwcDJryk6+WxZ1CI=
=/IOr
-----END PGP SIGNATURE-----

And this is why I live in pa, but make the trek in to the netherworld
known as new jersey. :D

On 1/16/08, Bill Moran <wmoran(at)potentialtech(dot)com> wrote:
> In response to dvanatta <dvanatta(at)yahoo(dot)com>:
>
> >
> > What's up with 3 of the 7 being from Pennsylvania? What's the connection?
>
> Well, as everyone knows, Pennsylvania is a haven for brilliant
> people. In fact, simply living in Pennsylvania makes you smarter.
>
> --
> Bill Moran
> http://www.potentialtech.com
>
> ---------------------------(end of broadcast)---------------------------
> TIP 1: if posting/reading through Usenet, please send an appropriate
> subscribe-nomail command to majordomo(at)postgresql(dot)org so that your
> message can get through to the mailing list cleanly
>

--
Kindest Regards,

Geoff

> From: Geoffrey Gowey
> Sounds reasonable, but what one manager answers today is subject to be
> changed by another tomorrow.

The intent is to get out in the open their "official" statement. That in turn may create a discussion inside Sun that may not have taken place.

If postgres community does not like the stand, then lobby to change it. Like you say, nothing either in time or by individual is forever locked in.

If the postgres community likes it, then be sure to continue to support Sun so that they continue in that direction. If they come out with a favorable strategy or had a planned strategy but kept it to themselves and postgres disses them, then they may take their toys and decide to play in other ways.

But get it out in the open as much as can be done. Simple. Then you know where they stand/don't-stand/or remain mute.

Then you can take further action.

Rumors/opinions are just that.

Postgres needs to have an "official spokesman" make a request at a "very important top official" that is responsible for the acquisition.

..Otto

Sounds reasonable, but what one manager answers today is subject to be
changed by another tomorrow.

On 1/16/08, Otto Hirr <otto(dot)hirr(at)olabinc(dot)com> wrote:
> > Russ Brown wrote:
> > > http://blogs.mysql.com/kaj/sun-acquires-mysql.html/
> > >
> > > What does this mean for Sun's support of Postgres?
> > >
>
> So why not go directly to the "source", Sun itself, and ask them?
>
> Someone like Bruce should just knock on the door and ask.
>
> Then you can evaluate the answer. Either a lie, the truth, or somewhere
> in-between, and the answer may only have a certain "shelf-life", for what is
> true today in the tech industry is false later.
>
> ..Otto
>
>
>
> ---------------------------(end of broadcast)---------------------------
> TIP 4: Have you searched our list archives?
>
> http://archives.postgresql.org/
>

--
Kindest Regards,

Geoff

Joshua D. Drake wrote:
> dvanatta <dvanatta(at)yahoo(dot)com> wrote:
>> What's up with 3 of the 7 being from Pennsylvania? What's the
>> connection?
>
> Its the closest the cult of the elephant will get to jersey.

Whoa now, them's fightin' words. Come on over and you me, Tony, Paulie
and Silvio will have a little chat.

--- Bill Moran <wmoran(at)potentialtech(dot)com> wrote:

> In response to dvanatta <dvanatta(at)yahoo(dot)com>:
>
> >
> > What's up with 3 of the 7 being from Pennsylvania?
> What's the connection?
>
> Well, as everyone knows, Pennsylvania is a haven for
> brilliant
> people. In fact, simply living in Pennsylvania
> makes you smarter.
>
Does it count if I lived there for a year many many
years ago? ;-)

Ted

On 16/01/2008 23:10, Ted Byers wrote:

> Does it count if I lived there for a year many many
> years ago? ;-)

...or if I visited for a day or two in 1986? ;-)

Ray.

---------------------------------------------------------------
Raymond O'Donnell, Director of Music, Galway Cathedral, Ireland
rod(at)iol(dot)ie
---------------------------------------------------------------

On Jan 16, 2008, at 4:02 PM, Otto Hirr wrote:

>> Postgres needs to have an "official spokesman" make a request at a
>> "very important top official" that is responsible for the
>> acquisition.
>
> ..Otto

Given that Josh Berkus works for Sun, I'd say we already have that.

Erik Jones

DBA | Emma®
erik(at)myemma(dot)com
800.595.4401 or 615.292.5888
615.292.0777 (fax)

Emma helps organizations everywhere communicate & market in style.
Visit us online at http://www.myemma.com

Otto Hirr wrote:
> Postgres needs to have an "official spokesman" make a request at a "very
> important top official" that is responsible for the acquisition.

Postgres doesn't need to do anything, because the matter at hand does not
concern Postgres, and I think we shouldn't spend our energy making it so.

Nevertheless, I suggest you follow Josh Berkus's blog, which is as close as
you will get to someone important from Postgres having access to someone
important at Sun.

--
Peter Eisentraut
http://developer.postgresql.org/~petere/

> > IsMySQLa direct competitor to Oracle? For the people who usemysql,
> > mostly smaller websites, oracle is not a realistic option.
>
> Smaller? Did you mean Larger?
>

I think what I mean is less mission critical. I have never heard of a
bank using MySQL as their main database system.

My point is, it does not seem to me that Oracle and MySQL compete head
to head. Most people who use Oracle would not consider MySQL for
anything critical. And most people who use MySQL would not consider
Oracle. For now, I think the two products target different markets. Of
course, that could change.

Before Sun acquired MySQL, I suspected that MySQL would be squeezed
between PostgreSQL and SQLite.

Good Morning Walter

dont forget MySQL also has support for simple commands such as
show databases
show tables

support for compiling and execution of Procedures in Postgres is nonexistent
99% of SQL code in either Oracle and MySQL DB's are written in
Procedures..trying to port that to Postgres is a very long and tedious
uphill climb

Comments?
Martin
----- Original Message -----
From: "walterbyrd" <walterbyrd(at)iname(dot)com>
To: <pgsql-general(at)postgresql(dot)org>
Sent: Sunday, January 20, 2008 9:34 AM
Subject: Re: [GENERAL] Sun acquires MySQL

> > > IsMySQLa direct competitor to Oracle? For the people who usemysql,
> > > mostly smaller websites, oracle is not a realistic option.
> >
> > Smaller? Did you mean Larger?
> >
>
> I think what I mean is less mission critical. I have never heard of a
> bank using MySQL as their main database system.
>
> My point is, it does not seem to me that Oracle and MySQL compete head
> to head. Most people who use Oracle would not consider MySQL for
> anything critical. And most people who use MySQL would not consider
> Oracle. For now, I think the two products target different markets. Of
> course, that could change.
>
> Before Sun acquired MySQL, I suspected that MySQL would be squeezed
> between PostgreSQL and SQLite.
>
> ---------------------------(end of broadcast)---------------------------
> TIP 3: Have you checked our extensive FAQ?
>
> http://www.postgresql.org/docs/faq
>

On Sun, Jan 20, 2008 at 11:33:43AM -0500, Martin Gainty wrote:
> dont forget MySQL also has support for simple commands such as
> show databases
Type: \d
> show tables
Type: \l

Not sure how it could be any simpler...

> support for compiling and execution of Procedures in Postgres is nonexistent
> 99% of SQL code in either Oracle and MySQL DB's are written in
> Procedures..trying to port that to Postgres is a very long and tedious
> uphill climb

Sorry? PostgreSQL supports SPs in several languages.. What exactly are
you referring to here?
--
Martijn van Oosterhout <kleptog(at)svana(dot)org> http://svana.org/kleptog/
> Those who make peaceful revolution impossible will make violent revolution inevitable.
> -- John F Kennedy

On Sun, 20 Jan 2008 17:46:19 +0100
Martijn van Oosterhout <kleptog(at)svana(dot)org> wrote:

> > support for compiling and execution of Procedures in Postgres is
> > nonexistent 99% of SQL code in either Oracle and MySQL DB's are
> > written in Procedures..trying to port that to Postgres is a very
> > long and tedious uphill climb
>
> Sorry? PostgreSQL supports SPs in several languages.. What exactly are
> you referring to here?

Technically postgresql doesn't support SPs, we support functions. I am
not exactly sure what the difference is but I can tell you that in
terms of Oracle we are pretty far behind (plpgsql vs plsql).

Sincerely,

Joshua D. Drake

Hello

>
> support for compiling and execution of Procedures in Postgres is nonexistent
> 99% of SQL code in either Oracle and MySQL DB's are written in
> Procedures..trying to port that to Postgres is a very long and tedious
> uphill climb
>

true compilation is necessary only for some cases (note: MySQL stored
procedures are not compiled too ~ PostgreSQL has similar language
plpgpsm with little bit faster execution
(http://www.pgsql.cz/index.php/SQL/PSM_Manual ). When plpgsql is
potentially slow, you can use perl or write own custom function in C,
what is simpler than with Oracle.

Regards
Pavel Stehule

-----BEGIN PGP SIGNED MESSAGE-----
Hash: RIPEMD160

>> dont forget MySQL also has support for simple commands such as
>> show databases
> Type: \d
>> show tables
> Type: \l
>
> Not sure how it could be any simpler...

Simpler, no, but it could be a lot more intuitive. I think having
psql recognize /^help/i would be a nice first step. Hmm, off to
write a quick patch...

- --
Greg Sabino Mullane greg(at)turnstep(dot)com
PGP Key: 0x14964AC8 200801201225
http://biglumber.com/x/web?pk=2529DF6AB8F79407E94445B4BC9B906714964AC8
-----BEGIN PGP SIGNATURE-----

iD8DBQFHk4pOvJuQZxSWSsgRAwLMAKDRHVWRpAW6sckQB6ZwzquRFx6cnACcCfHW
8qiiJhNNIOvCyDqe3wefYTQ=
=D2T3
-----END PGP SIGNATURE-----

On Sun, 20 Jan 2008 17:54:01 -0000
"Greg Sabino Mullane" <greg(at)turnstep(dot)com> wrote:

> > Not sure how it could be any simpler...
>
> Simpler, no, but it could be a lot more intuitive. I think having
> psql recognize /^help/i would be a nice first step. Hmm, off to
> write a quick patch...

+1

Joshua D. Drake

On Sun, Jan 20, 2008 at 05:54:01PM -0000, Greg Sabino Mullane wrote:
> Simpler, no, but it could be a lot more intuitive. I think having
> psql recognize /^help/i would be a nice first step. Hmm, off to
> write a quick patch...

When you start psql you get the nice message:
---
Welcome to psql 8.1.11, the PostgreSQL interactive terminal.

Type: \copyright for distribution terms
\h for help with SQL commands
\? for help with psql commands
\g or terminate with semicolon to execute query
\q to quit

I think people should be able to read and know that \? is how to get
help.

Have a nice day,
--
Martijn van Oosterhout <kleptog(at)svana(dot)org> http://svana.org/kleptog/
> Those who make peaceful revolution impossible will make violent revolution inevitable.
> -- John F Kennedy

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

On Sun, 20 Jan 2008 19:08:37 +0100
Martijn van Oosterhout <kleptog(at)svana(dot)org> wrote:

> Type: \copyright for distribution terms
> \h for help with SQL commands
> \? for help with psql commands
> \g or terminate with semicolon to execute query
> \q to quit
>
> I think people should be able to read and know that \? is how to get
> help.

If only it were that simple. I teach. I teach that exact statement you
say above. Guess what the two most often things happen in class.

How do I get help again?
Why isn't my query executing? (they always forget the ;).

\? Is counter intuitive. There is zero valid argument against that.

Yes they should be able to read the screen. There is zero valid
argument against that.

Most won't.

Worse there are two ways to get help... \h and \? and they aren't the
same thing. I don't have a solution for that one.

I think adding help to the psql prompt is a very sane way to help
people. It is human.

Sincerely,

Joshua D. Drake

>
> Have a nice day,

- --
The PostgreSQL Company: Since 1997, http://www.commandprompt.com/
Sales/Support: +1.503.667.4564 24x7/Emergency: +1.800.492.2240
Donate to the PostgreSQL Project: http://www.postgresql.org/about/donate
SELECT 'Training', 'Consulting' FROM vendor WHERE name = 'CMD'

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.6 (GNU/Linux)

iD8DBQFHk5WOATb/zqfZUUQRAnAHAJwIVdrdHZ2lMl9WsZlPrhDnopK9gwCfUNCo
qfYRfdbNoUp6oi3okZkCCkk=
=YCzE
-----END PGP SIGNATURE-----

On 20/01/2008, Greg Sabino Mullane <greg(at)turnstep(dot)com> wrote:
>
> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: RIPEMD160
>
>
> >> dont forget MySQL also has support for simple commands such as
> >> show databases
> > Type: \d
> >> show tables
> > Type: \l
> >
> > Not sure how it could be any simpler...
>
> Simpler, no, but it could be a lot more intuitive. I think having
> psql recognize /^help/i would be a nice first step. Hmm, off to
> write a quick patch...
>

I unlike it. It inconsistent!

all metacommands or psql commands starts with backslash.

regards
Pavel Stehule

> - --
> Greg Sabino Mullane greg(at)turnstep(dot)com
> PGP Key: 0x14964AC8 200801201225
> http://biglumber.com/x/web?pk=2529DF6AB8F79407E94445B4BC9B906714964AC8
> -----BEGIN PGP SIGNATURE-----
>
> iD8DBQFHk4pOvJuQZxSWSsgRAwLMAKDRHVWRpAW6sckQB6ZwzquRFx6cnACcCfHW
> 8qiiJhNNIOvCyDqe3wefYTQ=
> =D2T3
> -----END PGP SIGNATURE-----
>
>
>
> ---------------------------(end of broadcast)---------------------------
> TIP 1: if posting/reading through Usenet, please send an appropriate
> subscribe-nomail command to majordomo(at)postgresql(dot)org so that your
> message can get through to the mailing list cleanly
>

I love Postgresql to death, it's one of the shining stars of the Open Source
movement IMHO. It's rock solid, crashes less frequently than Oracle in my
experience, and does almost everything I could ask of it (granted - I don't
ask much often, just simple things like consistent behaviour, which seems to
elude many other products). My one biggest bone to pick with Postgresql is
that stored procedures are not compiled. It makes writing anything but the
most trivial things in plpgsql stupid because it will slow the crap out of
your queries. For example: I wrote a simple function to return the distance
between two lat longs in plpgsql. Not only did it choke on values that were
part of a valid domain when calling acos() (I have a list of them someplace
that I keep meaning to post as it seems like a really bad bug), it was
slow. I re-implemented in C and it was 8-12 times faster, and didn't error
out on acos for the same values. Expecting DBAs to be able to write
functions in C IMHO is a bit unrealistic. I am far from a typical DBA, I've
met precious few Oracle DBAs who could write functions in C. Trying to
implement good database code that is atomic and makes good use of functions
in Postgresql is an uphill battle because they slow the database down so
much.

On Jan 20, 2008 12:04 PM, Pavel Stehule <pavel(dot)stehule(at)gmail(dot)com> wrote:

> Hello
>
> >
> > support for compiling and execution of Procedures in Postgres is
> nonexistent
> > 99% of SQL code in either Oracle and MySQL DB's are written in
> > Procedures..trying to port that to Postgres is a very long and tedious
> > uphill climb
> >
>

This seems like a fallacious claim as MySQL only introduced procedures in
5.0 and their implementation was incomplete and has been kind of incremental
since 5.0 and still isn't complete, whereas plpgsql in Postgresql is a well
advanced implementation that works very well (Other than speed). Given that
it is also possible to implement functions in Perl, C, Java and Python, it
seems that you can achieve pretty much anything with a function in
Postgresql, which is not true in Oracle or MySQL. Oracle makes extensive
use of views and sql files, but not so much stored procs in the core distro
if I remember rightly, certainly not 99%.

>
>
> true compilation is necessary only for some cases (note: MySQL stored
> procedures are not compiled too ~ PostgreSQL has similar language
> plpgpsm with little bit faster execution
> (http://www.pgsql.cz/index.php/SQL/PSM_Manual ). When plpgsql is
> potentially slow, you can use perl or write own custom function in C,
> what is simpler than with Oracle.

Anyone who is using Perl for something that needs to be fast is seriously
misguided. My benchmarking to date shows that Perl is the slowest of the
mainstream second/third gen languages. Even python is faster and python
can be a dog (Having said that, python 3 looks to be about twice as fast
though which is quite an improvement)

True compilation is necessary for all cases if you care about scalability,
which ultimately everybody does as they will continue to run more and more
sites/databases on a set of servers until the CPU/IO limit is reached - it's
called business - you maximize resources. Plpgsql's lack of compilation
dramatically lowers that threshold, which means smaller profits for hosters
of Postgresql and serious limits on OLTP scalability when plpgsql functions
are utilized. Plus do you really want your hosted people writing functions
in C for your Postgresql? Hell, _I_ don't want to write functions in C for
Postgresql much, plpgsql is much less error prone and much easier to deal
with.

If I had to ask the Postgresql people to put one thing on the wish list for
the next major release it would be compiled functions, it's the one thing my
apps would benefit the most from as I like keeping data integrity, and
functions help me achieve that with elegance (I could tell you some stories
about data integrity with data feeds from other companies who clearly didn't
actually hire a DBA to design their database implementation, every row in
it's own transaction because you never know when it's going to violate
foreign key constraints, totally sucktastic). (The other thing would be
cache management, I know that my system would benefit hugely from being me
being able to direct certain tables to remain in memory regardless of MRU
data - It seems like something might be possible with RAM disks but how do
you sync it back to physical disk in a reliable way so that when your
machine dies your data doesn't buy the farm?).

Alex

On 21/01/2008, Alex Turner <armtuk(at)gmail(dot)com> wrote:
> I love Postgresql to death, it's one of the shining stars of the Open Source
> movement IMHO. It's rock solid, crashes less frequently than Oracle in my
> experience, and does almost everything I could ask of it (granted - I don't
> ask much often, just simple things like consistent behaviour, which seems to
> elude many other products). My one biggest bone to pick with Postgresql is
> that stored procedures are not compiled. It makes writing anything but the
> most trivial things in plpgsql stupid because it will slow the crap out of
> your queries. For example: I wrote a simple function to return the distance
> between two lat longs in plpgsql. Not only did it choke on values that were
> part of a valid domain when calling acos() (I have a list of them someplace
> that I keep meaning to post as it seems like a really bad bug), it was slow.
> I re-implemented in C and it was 8-12 times faster, and didn't error out on
> acos for the same values. Expecting DBAs to be able to write functions in C
> IMHO is a bit unrealistic. I am far from a typical DBA, I've met precious
> few Oracle DBAs who could write functions in C. Trying to implement good
> database code that is atomic and makes good use of functions in Postgresql
> is an uphill battle because they slow the database down so much.

Usability of plpgsql depend on case. There are some case where plpgsql
is useless: http://www.pgsql.cz/index.php/PL/pgSQL_%28en%29#When_is_PL.2FpgSQL_not_applicable

when you use plpgsql as glue of SQL statements, then speed of plpgsql
>> speed of SQL statements and there isn't problem. Your example is
real and I understand well, but bottleneck isn't in interpretation, is
it in evaluation of basic types, where C do this work simply and fast
and plpgsql call SQL expression evaluator. I am not sure if its
possible to write compiler for all supported platforms. I thinking
about plpgsql->c translator with some intelligence for detecting some
simply operations. Any sponsors?

Regards
Pavel Stehule

On Mon, Jan 21, 2008 at 02:47:32AM -0500, Alex Turner wrote:
> My one biggest bone to pick with Postgresql is
> that stored procedures are not compiled.

I'm not going go into this since in my experience they are fast enough
and I don't know enough of your context to decide if the problem has
been correctly diagnosed. plpgsql is not the fastest language supprted
by postgres.

> It makes writing anything but the
> most trivial things in plpgsql stupid because it will slow the crap out of
> your queries. For example: I wrote a simple function to return the distance
> between two lat longs in plpgsql.

Wrong tool for the job? If it's a single statement you should be using
lang 'sql' which would allow it to be inlined in your queries. I've
personally not found plpgsql to be so slow.

In this case, I would simply install postgis and you get all the speed
you need:

# select distance_sphere( makepoint(0,0), makepoint(0,180));
distance_sphere
------------------
20015045.5917028
(1 row)

> Not only did it choke on values that were
> part of a valid domain when calling acos() (I have a list of them someplace
> that I keep meaning to post as it seems like a really bad bug), it was
> slow.

Please report such bugs, since no-one else has seen this problem...

Have a nice day,
--
Martijn van Oosterhout <kleptog(at)svana(dot)org> http://svana.org/kleptog/
> Those who make peaceful revolution impossible will make violent revolution inevitable.
> -- John F Kennedy

On Jan 21, 2008 2:47 AM, Alex Turner <armtuk(at)gmail(dot)com> wrote:
> I re-implemented in C and it was 8-12 times faster, and didn't error out on
> acos for the same values. Expecting DBAs to be able to write functions in C

acos error on distance function is rounding issue, easy fix if you had
to do it this way (although this code really belongs in C).

> IMHO is a bit unrealistic. I am far from a typical DBA, I've met precious
> few Oracle DBAs who could write functions in C. Trying to implement good
> database code that is atomic and makes good use of functions in Postgresql
> is an uphill battle because they slow the database down so much.

While doing things like calculating distance are better handled in
languages like C, it is relatively trivial to wrap C libraries with
SQL and call them from in side sql or pl/pgsql procedures. Most of
the database functions I write are simply chaining SQL statements
together for presentation to the application or more complex queries.
pl/pgsql is very good at this...unless you know _exactly_ what you
are doing, writing these kinds of functions in C, which requires use
of SPI, will not get you anything on the performance side (and could
actually hurt, if you don't go through all the effort of plan
management).

In other words, pl/pgsql's speed disadvantages only matter if a
significant portion of the work is in doing things other than
executing queries and handling the results. Certainly, these types of
problems come up, but such cases are simply out of the scope of the
intended purpose of the language and there are many techniques dealing
with these problems. On the other hand, pl/pgsql is extremely easy to
write and debug, especially when running static sql. IMO, it is an
absolute must for any PostgreSQL DBA to master the language as well as
be aware of its limitations.

merlin

Merlin Moncure wrote:
> On Jan 21, 2008 2:47 AM, Alex Turner <armtuk(at)gmail(dot)com> wrote:
> In other words, pl/pgsql's speed disadvantages only matter if a
> significant portion of the work is in doing things other than
> executing queries and handling the results. Certainly, these types of
> problems come up, but such cases are simply out of the scope of the
> intended purpose of the language and there are many techniques dealing
> with these problems. On the other hand, pl/pgsql is extremely easy to
> write and debug, especially when running static sql. IMO, it is an
> absolute must for any PostgreSQL DBA to master the language as well as
> be aware of its limitations.
>
> merlin
>

Perhaps it would be useful to have a page in the documentation that
provides a brief comparison between the available pl languages
(including plpgsql and sql) and gives suggestions on the best one (or
ones) for given use cases?

--

Russ.

On Mon, 21 Jan 2008 08:01:49 -0600
Russ Brown <pickscrape(at)gmail(dot)com> wrote:

> Perhaps it would be useful to have a page in the documentation that
> provides a brief comparison between the available pl languages
> (including plpgsql and sql) and gives suggestions on the best one
> (or ones) for given use cases?

It'd be very appreciated.
I tried to read this:
http://www.pgsql.cz/index.php/PL/pgSQL_(en)#When_is_PL.2FpgSQL_not_applicable
But I'm not sure I really grasped it.

Some comparison/examples more may help.

BTW today pg 8.3-rc2 reached Debian sid amd64 and I took a chance to
see what was available... and there is support for a *lot* of
languages now.

I started to develop a lot of functions code thinking that pgsql was
the nearest thing to the metal after plain sql and after these post I
was wondering if python (or ruby??) would have made a better choice.

My main concern when I chose the function route was limiting the
number of connections and hiding the underlying structure of the DB
to the client application.

--
Ivan Sergio Borgonovo
http://www.webthatworks.it

"Pavel Stehule" <pavel(dot)stehule(at)gmail(dot)com> writes:
> when you use plpgsql as glue of SQL statements, then speed of plpgsql
> speed of SQL statements and there isn't problem. Your example is
> real and I understand well, but bottleneck isn't in interpretation, is
> it in evaluation of basic types, where C do this work simply and fast
> and plpgsql call SQL expression evaluator. I am not sure if its
> possible to write compiler for all supported platforms. I thinking
> about plpgsql->c translator with some intelligence for detecting some
> simply operations. Any sponsors?

That's probably not worth the amount of effort it would take.

The bottom line is: if you're doing computationally expensive
non-SQL-query operations, plpgsql is simply the wrong language for the
job ... and it's not like there are not plenty of others to choose from.
I'd expect plperl or even pltcl to be faster for such things (I have no
idea about the speed of other scripting languages such as python or
ruby). Or pl/java. Also, if what you're doing fits within its
capabilities, pl/R is an interesting alternative.

regards, tom lane

Tom Lane wrote:
> The bottom line is: if you're doing computationally expensive
> non-SQL-query operations, plpgsql is simply the wrong language for the
> job ... and it's not like there are not plenty of others to choose from.
> I'd expect plperl or even pltcl to be faster for such things (I have no
> idea about the speed of other scripting languages such as python or
> ruby). Or pl/java. Also, if what you're doing fits within its
> capabilities, pl/R is an interesting alternative.

Unfortunately, I think the stored procedure implementation in PG itself
introduces significant overhead. See thread "Writing most code in
Stored Procedures" from August 2007. I converted an application from
that BigDBMS we are not allowed to mention to PG. Code is Java, stored
procs were written in PL/Java. On the exact same hardware, I couldn't
get any where near the throughput I was getting in BigDBMS. The procs
are trivial - just wrappers for insert statements. After I exhausted
all alternatives, I replaced the stored proc invocation in the code with
inserts. Then, PG was able to achieve the same throughput as BigDBMS.

--
Guy Rouillier

Guy Rouillier <guyr-ml1(at)burntmail(dot)com> writes:
> Unfortunately, I think the stored procedure implementation in PG itself
> introduces significant overhead. See thread "Writing most code in
> Stored Procedures" from August 2007. I converted an application from
> that BigDBMS we are not allowed to mention to PG. Code is Java, stored
> procs were written in PL/Java. On the exact same hardware, I couldn't
> get any where near the throughput I was getting in BigDBMS. The procs
> are trivial - just wrappers for insert statements. After I exhausted
> all alternatives, I replaced the stored proc invocation in the code with
> inserts. Then, PG was able to achieve the same throughput as BigDBMS.

I doubt that what you were measuring there was either procedure call
overhead or java computational speed; more likely it was the cost of
calling back out of java, through pl/java's JDBC emulation, down through
SPI, to re-execute the same INSERT that you then decided to execute
directly. In particular, if pl/java's JDBC doesn't know anything about
caching query plans, performance for simple inserts could be expected to
go into the tank just because of that. (Whether it actually does or
not, I have no idea --- but I would expect it to be a lot less mature
than the mainstream JDBC driver for PG, and that took years to get
smart about prepared queries ...)

Without knowing where the bottleneck actually is, it's unreasonable to
assume that it would hurt a different use-case.

regards, tom lane

On Monday 21 January 2008 04:47:40 pm Tom Lane wrote:
> Guy Rouillier <guyr-ml1(at)burntmail(dot)com> writes:
> > Unfortunately, I think the stored procedure implementation in PG itself
> > introduces significant overhead. See thread "Writing most code in
> > Stored Procedures" from August 2007. I converted an application from
> > that BigDBMS we are not allowed to mention to PG. Code is Java, stored
> > procs were written in PL/Java. On the exact same hardware, I couldn't
> > get any where near the throughput I was getting in BigDBMS. The procs
> > are trivial - just wrappers for insert statements. After I exhausted
> > all alternatives, I replaced the stored proc invocation in the code with
> > inserts. Then, PG was able to achieve the same throughput as BigDBMS.
>
> I doubt that what you were measuring there was either procedure call
> overhead or java computational speed; more likely it was the cost of
> calling back out of java, through pl/java's JDBC emulation, down through
> SPI, to re-execute the same INSERT that you then decided to execute
> directly. In particular, if pl/java's JDBC doesn't know anything about
> caching query plans, performance for simple inserts could be expected to
> go into the tank just because of that. (Whether it actually does or
> not, I have no idea --- but I would expect it to be a lot less mature
> than the mainstream JDBC driver for PG, and that took years to get
> smart about prepared queries ...)
>
> Without knowing where the bottleneck actually is, it's unreasonable to
> assume that it would hurt a different use-case.

Tom,
I have read several of your post on store procedure performance. Why not give
us your take on what works and what does not.

--
John Fabiani

On Mon, 21 Jan 2008 21:31:23 -0800
johnf <jfabiani(at)yolo(dot)com> wrote:

> On Monday 21 January 2008 04:47:40 pm Tom Lane wrote:

> > I doubt that what you were measuring there was either procedure
> > call overhead or java computational speed; more likely it was the
> > cost of calling back out of java, through pl/java's JDBC
> > emulation, down through SPI, to re-execute the same INSERT that
> > you then decided to execute directly. In particular, if
> > pl/java's JDBC doesn't know anything about caching query plans,
> > performance for simple inserts could be expected to go into the
> > tank just because of that. (Whether it actually does or not, I
> > have no idea --- but I would expect it to be a lot less mature
> > than the mainstream JDBC driver for PG, and that took years to
> > get smart about prepared queries ...)

> > Without knowing where the bottleneck actually is, it's
> > unreasonable to assume that it would hurt a different use-case.

> Tom,
> I have read several of your post on store procedure performance.
> Why not give us your take on what works and what does not.

Yep, the more I read, the more I get confused.
Java loading overhead is a common myth (I can't say if true or false),
and what Tom writes above can find a tentative place in my mind.
But still then I can't understand where plsql should or shouldn't be
used.

I really would enjoy to see some general guideline on how to chose.

thanks

--
Ivan Sergio Borgonovo
http://www.webthatworks.it

On Jan 22, 2008 2:24 AM, Ivan Sergio Borgonovo <mail(at)webthatworks(dot)it> wrote:
> > > I doubt that what you were measuring there was either procedure
> > > call overhead or java computational speed; more likely it was the
> > > cost of calling back out of java, through pl/java's JDBC
> > > emulation, down through SPI, to re-execute the same INSERT that
> > > you then decided to execute directly. In particular, if
> > > pl/java's JDBC doesn't know anything about caching query plans,
> > > performance for simple inserts could be expected to go into the
> > > tank just because of that. (Whether it actually does or not, I
> > > have no idea --- but I would expect it to be a lot less mature
> > > than the mainstream JDBC driver for PG, and that took years to
> > > get smart about prepared queries ...)
>
> > > Without knowing where the bottleneck actually is, it's
> > > unreasonable to assume that it would hurt a different use-case.
>
> > Tom,
> > I have read several of your post on store procedure performance.
> > Why not give us your take on what works and what does not.
>
> Yep, the more I read, the more I get confused.
> Java loading overhead is a common myth (I can't say if true or false),
> and what Tom writes above can find a tentative place in my mind.
> But still then I can't understand where plsql should or shouldn't be
> used.

It's fairly trivial to test performance of functions vs. raw
statements, or just about anything going on with the server. The
benchmarking tool, pgbench, allows custom sql which is great for
things like this. It would have shown you that functions themselves
are not the reason why your application was not running quickly. My
seat of the pants guess (I don't do java) was that your problem was in
the jdbc driver somewhere. When using a high level database framework
like jdbc or ado.net, it can be difficult to figure out exactly what
is going on with the database at times...I tend to avoid them.

merlin

>
> Yep, the more I read, the more I get confused.
> Java loading overhead is a common myth (I can't say if true or false),
> and what Tom writes above can find a tentative place in my mind.
> But still then I can't understand where plsql should or shouldn't be
> used.
>
> I really would enjoy to see some general guideline on how to chose.
>

1. use procedure lot of SQL statements --> use plpgsql
2. procedure needs some untrusted functionality -> use untrusted language
3. procedure contains only expressions
3.a) isn't too much important --> use plpgsql don't forgot IMMUTABLE flag
3.b) is important and is bottleneck --> try perl
3.c) is most important or is wide used --> use C
3.d) is simply implemented in C (some time, string fce) --> use C

learn some trick:

create or replace function list(int)
returns varchar as $$
declare s varchar = '';
begin
for i in 1..$1 loop
s := s || '<item>' || i || '</item>';
end loop;
return s;
end; $$ language plpgsql;

postgres=# select list(10);

list
-----------------------------------------------------------------------------------------------------------------------------------------------
<item>1</item><item>2</item><item>3</item><item>4</item><item>5</item><item>6</item><item>7</item><item>8</item><item>9</item><item>10</item>
(1 row)

Time: 0,927 ms -- well

number, time
100, 5ms
1000, 75ms ... usable
10000, 4s ... slow

so if I use fce list with param < 1000 I can use plpgsql without any
problems. With bigger value I have problem. But I forgot IMMUTABLE,
ook try again:

100, 4ms
1000, 70ms
10000, 3.8s ok IMMUTABLE doesn't help here

what is bottleneck? FOR?

create or replace function list(int)
returns varchar as $$
declare s varchar = '';
begin
for i in 1..$1 loop
perform '<item>' || i || '</item>';
end loop;
return s;
end; $$ language plpgsql immutable;

10000, 443 ms ..

bottleneck is in repeated assign s := s || ..

I will try trick:

create or replace function list(int)
returns varchar as $$
begin
return array_to_string(array(select '<item>' || i || '</item>'
from generate_series(1, $1) g(i)), '');
end$$ language plpgsql immutable;

test
100, 1.3ms
1000, 7.64ms
10000, 63ms -- nice I don't need C
100000, 350ms
Regards

Pavel Stehule

> thanks
>
> --
> Ivan Sergio Borgonovo
> http://www.webthatworks.it
>
>
> ---------------------------(end of broadcast)---------------------------
> TIP 4: Have you searched our list archives?
>
> http://archives.postgresql.org/
>

Pavel Stehule wrote:
>
> ...
>
> bottleneck is in repeated assign s := s || ..
>
> I will try trick:
>
> create or replace function list(int)
> returns varchar as $$
> begin
> return array_to_string(array(select '<item>' || i || '</item>'
> from generate_series(1, $1) g(i)), '');
> end$$ language plpgsql immutable;
>
> test
> 100, 1.3ms
> 1000, 7.64ms
> 10000, 63ms -- nice I don't need C
> 100000, 350ms
> Regards
>
> Pavel Stehule
>

That's some trick! Thanks for the lessons, Pavel.

b