| Lists: | pgsql-performance |
|---|
| From: | Jeffrey Tenny <jeffrey(dot)tenny(at)comcast(dot)net> |
|---|---|
| To: | pgsql-performance(at)postgresql(dot)org |
| Subject: | Re: Need help to decide Mysql vs Postgres |
| Date: | 2005-06-06 15:51:22 |
| Message-ID: | 42A470FA.1080001@comcast.net |
| Views: | Raw Message | Whole Thread | Download mbox | Resend email |
| Lists: | pgsql-performance |
Re: your JDBC wishes: Consider IBM Cloudscape (now Apache Derby) too,
which has an apache license. It's all pure java and it's easy to get going.
As to MySql vs Postgres: license issues aside, if you have
transactionally complex needs (multi-table updates, etc), PostgreSQL
wins hands down in my experience. There are a bunch of things about
MySQL that just suck for high end SQL needs. (I like my subqueries,
and I absolutely demand transactional integrity).
There are some pitfalls to pgsql though, especially for existing SQL
code using MAX and some other things which can really be blindsided
(performance-wise) by pgsql if you don't use the workarounds.
MySQL is nice for what I call "raw read speed" applications. But that
license is an issue for me, as it is for you apparently.
Some cloudscape info:
http://www-306.ibm.com/software/data/cloudscape/
Some info on pitfalls of MySQL and PostgreSQL, an interesting contrast:
http://sql-info.de/postgresql/postgres-gotchas.html
http://sql-info.de/mysql/gotchas.html
| From: | Tobias Brox <tobias(at)nordicbet(dot)com> |
|---|---|
| To: | Jeffrey Tenny <jeffrey(dot)tenny(at)comcast(dot)net> |
| Cc: | pgsql-performance(at)postgresql(dot)org |
| Subject: | Re: Need help to decide Mysql vs Postgres |
| Date: | 2005-06-06 17:25:08 |
| Message-ID: | 20050606172508.GB8451@tobias.nordicbet.com |
| Views: | Raw Message | Whole Thread | Download mbox | Resend email |
| Lists: | pgsql-performance |
[Jeffrey Tenny - Mon at 11:51:22AM -0400]
> There are some pitfalls to pgsql though, especially for existing SQL
> code using MAX and some other things which can really be blindsided
> (performance-wise) by pgsql if you don't use the workarounds.
Yes, I discovered that - "select max(num_attr)" does a full table scan even
if the figure can be found easily through an index.
There exists a workaround:
select num_attr from my_table order by num_attr desc limit 1;
will find the number through the index.
--
Tobias Brox, Tallinn
| From: | Michael Fuhr <mike(at)fuhr(dot)org> |
|---|---|
| To: | Tobias Brox <tobias(at)nordicbet(dot)com> |
| Cc: | Jeffrey Tenny <jeffrey(dot)tenny(at)comcast(dot)net>, pgsql-performance(at)postgresql(dot)org |
| Subject: | Re: Need help to decide Mysql vs Postgres |
| Date: | 2005-06-06 18:33:40 |
| Message-ID: | 20050606183340.GA38889@winnie.fuhr.org |
| Views: | Raw Message | Whole Thread | Download mbox | Resend email |
| Lists: | pgsql-performance |
On Mon, Jun 06, 2005 at 08:25:08PM +0300, Tobias Brox wrote:
> [Jeffrey Tenny - Mon at 11:51:22AM -0400]
> > There are some pitfalls to pgsql though, especially for existing SQL
> > code using MAX and some other things which can really be blindsided
> > (performance-wise) by pgsql if you don't use the workarounds.
>
> Yes, I discovered that - "select max(num_attr)" does a full table scan even
> if the figure can be found easily through an index.
PostgreSQL 8.1 will be able to use indexes for MIN and MAX.
http://archives.postgresql.org/pgsql-committers/2005-04/msg00163.php
http://archives.postgresql.org/pgsql-committers/2005-04/msg00168.php
--
Michael Fuhr
http://www.fuhr.org/~mfuhr/