Thread: Two questions from the boss (SQL:2003 && scalability)
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
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
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.
> 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
I've worked with Oracle, Interbase, and Informix. PostgreSQL is the most
SQL spec compliant of any of them, whether the spec is 89, 92, or 03. I
have not worked with MySQL.
Rick
Robert Treat
<xzilla@users.sourcefor To: John Wells <jbwellsiv@gmail.com>
ge.net> cc: "pgsql-general@postgresql.org"
<pgsql-general@postgresql.org>
Sent by: Subject: Re: [GENERAL] Two questions from the boss (SQL:2003 &&
scalability)
pgsql-general-owner@pos
tgresql.org
10/21/2004 03:56 PM
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
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 | ajs@crankycanuck.ca
The fact that technology doesn't work is no bar to success in the marketplace.
--Philip Greenspun
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 majordomo@postgresql.org -- #======================================================================# # It's easier to get forgiveness for being wrong than for being right. # # Let's break this rule - forgive me. # #================================================== JanWieck@Yahoo.com #
On Fri, 22 Oct 2004 14:18:52 -0400, Jan Wieck <janwieck@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.