> If you strictly have an OLTP workload, with lots of simultaneous
> connections issuing queries across small chunks of data, then
> PostgreSQL would be a good match for SQL server.
This matches my observations. In fact, PostgreSQL's MVCC seems to work
heavily in my favor in OLTP workloads.
> On
Tom Polak wrote:
Hi neighbor! (We're just up I90/I39 a bit.)
> What kind of performance can I expect out of Postgres compare to
> MSSQL?
I can't speak directly to MS SQL Server 2000, but Sybase and ASE have
common roots; I think MS SQL Server 2000 is still using the engine
that they inherit
> The real performance problem with RAID 5 won't show up until a drive
> dies and it starts rebuilding
I don't agree with that. RAID5 is very slow for random writes, since
it needs to :
"The real problem" is when RAID5 loses a drive and goes from "acceptable"
kind of slow, to "someone'
2010/12/18 Gael Le Mignot :
> Hello Scott!
>
> Fri, 17 Dec 2010 19:06:15 -0700, you wrote:
>
> > On Fri, Dec 17, 2010 at 10:32 AM, Craig James
> > wrote:
> >> RAID5 is a Really Bad Idea for any database. It is S...L...O...W. It
> does
> >> NOT give better redundancy and security; RAID 10 wi
Hello Scott!
Fri, 17 Dec 2010 19:06:15 -0700, you wrote:
> On Fri, Dec 17, 2010 at 10:32 AM, Craig James
> wrote:
>> RAID5 is a Really Bad Idea for any database. It is S...L...O...W. It does
>> NOT give better redundancy and security; RAID 10 with a battery-backed RAID
>> controller card
On Fri, Dec 17, 2010 at 10:32 AM, Craig James
wrote:
> RAID5 is a Really Bad Idea for any database. It is S...L...O...W. It does
> NOT give better redundancy and security; RAID 10 with a battery-backed RAID
> controller card is massively better for performance and just as good for
> redundancy a
On Fri, Dec 17, 2010 at 12:49 PM, Tom Polak
wrote:
> That is what I am really after. I know that it will be a lot of work, but
> at $15,000 for MSSQL server that is a lot of man hours. Before I invest a
> lot of time to do some real benchmarking I need to make sure it would be
> worth my time.
l Message-
From: Robert Haas [mailto:robertmh...@gmail.com]
Sent: Friday, December 17, 2010 11:38 AM
To: Tom Polak
Cc: pgsql-performance@postgresql.org
Subject: Re: [PERFORM] Compared MS SQL 2000 to Postgresql 9.0 on Windows
On Fri, Dec 17, 2010 at 12:08 PM, Tom Polak
wrote:
> What kind of
On 12/17/2010 11:37 AM, Robert Haas wrote:
On Fri, Dec 17, 2010 at 12:08 PM, Tom Polak
wrote:
other direction to get good performance, too. You're not going to
compare two major database systems across the board and find that one
of them is just twice as fast, across the board. They have d
On 12/17/2010 11:08 AM, Tom Polak wrote:
So, I am back on this topic again.
I have a related question, but this might be the correct thread (and
please let me know that). The boss is pressing the issue because of the
cost of MSSQL.
What kind of performance can I expect out of Postgres compare t
On Fri, Dec 17, 2010 at 12:08 PM, Tom Polak
wrote:
> What kind of performance can I expect out of Postgres compare to MSSQL?
> Let's assume that Postgres is running on Cent OS x64 and MSSQL is running
> on Windows 2008 x64, both are on identical hardware running RAID 5 (for
> data redundancy/secur
On Fri, Dec 17, 2010 at 10:08 AM, Tom Polak
wrote:
> What kind of performance can I expect out of Postgres compare to MSSQL?
You should take any generalizations with a grain of salt. I suggest
that you do a POC.
> Let's assume that Postgres is running on Cent OS x64 and MSSQL is running
> on Win
On Fri, Dec 17, 2010 at 9:08 AM, Tom Polak
wrote:
> Any comparisons in terms of performance would be great. If not, how can I
> quickly truly compare the two systems myself without coding everything to
> work for both? Thoughts? Opinions?
I can only offer anecdotal information.
If you strictl
On 12/17/10 9:08 AM, Tom Polak wrote:
So, I am back on this topic again.
I have a related question, but this might be the correct thread (and
please let me know that). The boss is pressing the issue because of the
cost of MSSQL.
You need to analyze the total cost of the system. For the price
pared MS SQL 2000 to Postgresql 9.0 on Windows
> The hardware it
> is running on is fairly good, dual Xeon CPUs, 4 GB of RAM, Raid 5.
For a database you'd want to consider replacing the RAID1 with a RAID1 (or
RAID10). RAID5 is slow for small random updates, which are common in
data
The hardware it
is running on is fairly good, dual Xeon CPUs, 4 GB of RAM, Raid 5.
For a database you'd want to consider replacing the RAID1 with a RAID1 (or
RAID10). RAID5 is slow for small random updates, which are common in
databases. Since you probably have enough harddisks anyway, this
Tom Polak wrote:
> I did not tweak anything after installing either system.
PostgreSQL is set up with defaults such that it will start up and
run on the most ancient an underpowered system people are likely to
have lying around. It is expected that people will tune it for
serious production u
On 07/12/2010 9:29 PM, Tom Polak wrote:
From EXPLAIN ANALYZE I can see the query ran much faster.
"Nested Loop Left Join (cost=0.00..138.04 rows=1001 width=1298) (actual
time=0.036..4.679 rows=1001 loops=1)"
" Join Filter: (pgtemp1.state = pgtemp2.stateid)"
" -> Seq Scan on pgtemp1 (cost=
r, please immediately
notify us by telephone and reply email. Thank you.
Although this email and any attachments are believed to be free of any
viruses or other defects that might affect any computer system into which
it is received and opened, it is the responsibility of the recipient to
ensure tha
s or other defects that might affect any computer system into which
it is received and opened, it is the responsibility of the recipient to
ensure that it is free of viruses, and the Rockford Area Association of
Realtors hereby disclaims any liability for any loss or damage that
results.
-Original
On 12/7/2010 2:10 PM, Kenneth Marshall wrote:
On Tue, Dec 07, 2010 at 11:56:51AM -0800, Richard Broersma wrote:
On Tue, Dec 7, 2010 at 11:43 AM, Andy Colson wrote:
In PG the first statement you fire off (like an "insert into" for example)
will start a transaction. ?If you dont commit before y
Tom Polak wrote:
We are in the process of deciding on how to proceed on a database
upgrade. We currently have MS SQL 2000 running on Windows 2003 (on my
test server). I was shocked at the cost for MS SQL 2008 R2 for a new
server (2 CPU license). I started comparing DB’s and came across
po
On 07/12/2010 7:43 PM, Andy Colson wrote:
On 12/7/2010 1:22 PM, Justin Pitts wrote:
Also, as a fair warning: mssql doesn't really care about
transactions, but
PG really does. Make sure all your code is properly starting and
commiting
transactions.
-Andy
I do not understand that statement
On Tue, Dec 07, 2010 at 11:56:51AM -0800, Richard Broersma wrote:
> On Tue, Dec 7, 2010 at 11:43 AM, Andy Colson wrote:
>
> > In PG the first statement you fire off (like an "insert into" for example)
> > will start a transaction. ?If you dont commit before you disconnect that
> > transaction wil
On Tue, Dec 7, 2010 at 11:43 AM, Andy Colson wrote:
> In PG the first statement you fire off (like an "insert into" for example)
> will start a transaction. If you dont commit before you disconnect that
> transaction will be rolled back. Even worse, if your program does not
> commit, but keeps
On 12/7/2010 1:22 PM, Justin Pitts wrote:
Also, as a fair warning: mssql doesn't really care about transactions, but
PG really does. Make sure all your code is properly starting and commiting
transactions.
-Andy
I do not understand that statement. Can you explain it a bit better?
In mssql
On 12/7/10 9:34 AM, Tom Polak wrote:
We are in the process of deciding on how to proceed on a database upgrade. We
currently have MS SQL 2000 running on Windows 2003 (on my test server). I was
shocked at the cost for MS SQL 2008 R2 for a new server (2 CPU license). I
started comparing DB’s
On Tuesday 07 December 2010 18:34:25 Tom Polak wrote:
> Then I did the same test via Postgresql and it took 8.85 seconds! I tried
> it again as I thought I did something wrong. I did a few tweaks such as
> increasing the shared buffers. Still the best I could get it to was 7.5
> seconds. This i
On 12/7/2010 11:34 AM, Tom Polak wrote:
We are in the process of deciding on how to proceed on a database
upgrade. We currently have MS SQL 2000 running on Windows 2003 (on my
test server). I was shocked at the cost for MS SQL 2008 R2 for a new
server (2 CPU license). I started comparing DB’s
Tom Polak wrote:
> the best I could get it to was 7.5 seconds.
> select name,address,city,state,statename,stateid,other from
> pgtemp1 left join pgtemp2 on state=stateid
We'd need a lot more information. Please read this and post again:
http://wiki.postgresql.org/wiki/SlowQueryQuestions
30 matches
Mail list logo
