Two questions from the boss (SQL:2003 && scalability)

[John Wells]

Guys,

My boss has been keeping himself busy reading MySQL marketing pubs,
and came at me with a few questions this morning regarding PostgreSQL
features (we're currently moving to PostgreSQL).

While I don't think either are really that important for our
situation, he wanted to know specifically whether PostgreSQL supported
SQL:2003, and what sort of capabilities PostgreSQL has to scale across
multiple CPUs and hosts (multithreading, load balancing, etc).

I appreciate any input you can provide.

Thanks,
JB

---------------------------(end of broadcast)---------------------------
TIP 1: subscribe and unsubscribe commands go to ma*******@postgresql.org

[Robert Treat]

On Thu, 2004-10-21 at 15:40, John Wells wrote:

Guys,

My boss has been keeping himself busy reading MySQL marketing pubs,
and came at me with a few questions this morning regarding PostgreSQL
features (we're currently moving to PostgreSQL).

I'd be interested to see what my$ql has to say about SQL:2003
compliance...
While I don't think either are really that important for our
situation, he wanted to know specifically whether PostgreSQL supported
SQL:2003,
Well, certainly it is not in full compliance, but then who is? I would
say that most of the new features in SQL:2003 are not supported yet,
however if you run into a specific one that you could actually use post
to the list and you'll likely get a good work-around.

and what sort of capabilities PostgreSQL has to scale across multiple CPUs and hosts (multithreading, load balancing, etc).

Well, PostgreSQL can certainly take advantage of multiple CPU's,
although there are some cases where we could do more (use multiple CPU
on one query). You can also use a combination of tools like pgpool and
slony to set up load balancing depending on your needs... though I
should say that PostgreSQL has tremendous ability to scale up even
without getting into all the buzzword friendly schemes.
Robert Treat
--
Build A Brighter Lamp :: Linux Apache {middleware} PostgreSQL
---------------------------(end of broadcast)---------------------------
TIP 7: don't forget to increase your free space map settings

[Ben]

On 21 Oct 2004, Robert Treat wrote:

slony to set up load balancing depending on your needs... though I
should say that PostgreSQL has tremendous ability to scale up even
without getting into all the buzzword friendly schemes.

You should strive to pool your connections, though. Of course, that's just
common sense, but for postgres it might also make a big difference,
depending on your usage.
---------------------------(end of broadcast)---------------------------
TIP 2: you can get off all lists at once with the unregister command
(send "unregister YourEmailAddressHere" to ma*******@postgresql.org)

[Jeff Davis]

and what sort of capabilities PostgreSQL has to scale across

multiple CPUs and hosts (multithreading, load balancing, etc).

Well, PostgreSQL can certainly take advantage of multiple CPU's,
although there are some cases where we could do more (use multiple CPU
on one query). You can also use a combination of tools like pgpool and
slony to set up load balancing depending on your needs... though I
should say that PostgreSQL has tremendous ability to scale up even
without getting into all the buzzword friendly schemes.

Just to clarify, PostgreSQL uses multiple processes rather than, e.g.
multiple threads. The developers agree that multiple processes provide
more benefits (mostly in stability and robustness) than costs (more
connection startup costs). The startup costs are easily overcome by
using connection pooling.

Also, each query can only use one processor; a single query can't be
executed in parallel across many CPUs. However, several queries running
concurrently will be spread across the available CPUs.

Slony <http://slony.info> and something like pgpool
<http://www2b.biglobe.ne.jp/~caco/pgpool/index-e.html> can work together
to make a great replication system with load balancing. No one
replication solution is perfect for all, and PostgreSQL has other
options, so you should post your business's needs if you want more
specific advice.

Regards,
Jeff Davis


---------------------------(end of broadcast)---------------------------
TIP 1: subscribe and unsubscribe commands go to ma*******@postgresql.org

[Andrew Sullivan]

On Thu, Oct 21, 2004 at 03:40:23PM -0400, John Wells wrote:

Guys,

My boss has been keeping himself busy reading MySQL marketing pubs,
and came at me with a few questions this morning regarding PostgreSQL
features (we're currently moving to PostgreSQL).
I should point out that there's a whoile bunch of folks on the
-advocacy list who'd love to do any debunking necessary, if you want.
situation, he wanted to know specifically whether PostgreSQL supported
SQL:2003,
I know of no system which completely meets SQL 2003. Many of the
features in the 2003 standard are available in PostgreSQL, however,
and compliance with the standard is very much the goal of the
project. Given that MySQL has possibly the worst SQL standards
conformance of all systems claiming to conform, I can't imagine this
would be a real point of contention. (Note that MySQL is getting
much better on this front, but they still have a very long way to
go.)
and what sort of capabilities PostgreSQL has to scale across
multiple CPUs and hosts (multithreading, load balancing, etc).

PostgreSQL can scale across multiple CPUs, but it is not
multithreaded. Of the "across hosts" question refers to the new
table handler which sort-of mostly provides multi-master capability
to MySQL, I suggest _very strongly_ you get all the details on that
system before plonking down your money. There are some remarkably
serious problems with it, in my (not very humble) opinion. I did an
analysis of it this year for my employers. I'm not at liberty to
publish the resulting memo, but I would say that, at the very least,
it's important to understand how the table types, concurrency, and
transaction control all work together. (I believe one value for
"work together" there is "don't".)

A

--
Andrew Sullivan | aj*@crankycanuck.ca
The fact that technology doesn't work is no bar to success in the marketplace.
--Philip Greenspun

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

[Jan Wieck]

On 10/21/2004 3:40 PM, John Wells wrote:

Guys,

My boss has been keeping himself busy reading MySQL marketing pubs,
and came at me with a few questions this morning regarding PostgreSQL
features (we're currently moving to PostgreSQL).

While I don't think either are really that important for our
situation, he wanted to know specifically whether PostgreSQL supported
SQL:2003, and what sort of capabilities PostgreSQL has to scale across
multiple CPUs and hosts (multithreading, load balancing, etc).
That "multiple hosts" sounds that he came across the NDB cluster stuff
that will become available in MySQL someday. Be aware that this new
table handler will to my knowledge NOT support foreign keys. So the
enforcement of referential integrity is back to the application, now in
a multimaster cluster. I don't think that's a good idea, nor do I think
it will be easier to add this later instead of doing it right in the
initial design phase, but my way of solving problems is not the way
MySQL plans their features.
Jan

I appreciate any input you can provide.

Thanks,
JB

---------------------------(end of broadcast)---------------------------
TIP 1: subscribe and unsubscribe commands go to ma*******@postgresql.org

--
#================================================= =====================#
# It's easier to get forgiveness for being wrong than for being right. #
# Let's break this rule - forgive me. #
#================================================= = Ja******@Yahoo.com #

---------------------------(end of broadcast)---------------------------
TIP 4: Don't 'kill -9' the postmaster

[Kevin Barnard]

On Fri, 22 Oct 2004 14:18:52 -0400, Jan Wieck <ja******@yahoo.com> wrote:

That "multiple hosts" sounds that he came across the NDB cluster stuff
that will become available in MySQL someday. Be aware that this new
table handler will to my knowledge NOT support foreign keys. So the
enforcement of referential integrity is back to the application, now in
a multimaster cluster. I don't think that's a good idea, nor do I think
it will be easier to add this later instead of doing it right in the
initial design phase, but my way of solving problems is not the way
MySQL plans their features.

This is the major difference in philosphies between open source
projects that are controlled by a company whose profit depends on
sales of the product (MySQL AB) and a project that is feature funded
by companines that actually need the features they are
funding(PostgreSQL)

So of course the are "selling" a feature regardless of it's need to be
functional.

---------------------------(end of broadcast)---------------------------
TIP 4: Don't 'kill -9' the postmaster