> > Yes, you are rigth... my insert/update are very
> simple
> > and without problems and so I think to use
> 'foreign
> > key' coded to make faster/simpler the management
> and
> > don't overloading the db (and use exception code
> > management )... but I had a problem with pgSQL
> because
> > ser
> > No, I haven't foreign keys in the older version,
> in
> > that new I've it... however I manage relations
> from
> > app code (PHP)...
>
> Really ?
> In my experience this is a sure way to get
> inconsistencies slowly
> creeping into your database, and you also get a load
> of fun
--- PFC <[EMAIL PROTECTED]> wrote:
> You mean, you have no foreign keys in your database
?
> In SELECT they are definitely useful (think select
> for update, isolation
> level serializable...)
No, I haven't foreign keys in the older version, in
that new I've it... however I manage re
Really ?
In my experience this is a sure way to get
inconsistencies slowly
creeping into your database, and you also get a load
of funky concurrency
issues.
Yes, you are rigth... my insert/update are very simple
and without problems and so I think to use 'foreign
key' coded to make
No, I haven't foreign keys in the older version, in
that new I've it... however I manage relations from
app code (PHP)...
Really ?
In my experience this is a sure way to get inconsistencies slowly
creeping into your database, and you also get a load of funky concurrency
issues.
doesn't MYSQ
I don't require transaction because the query aren't
complex and update a single tuple (in SELECT
transactions are useless)
You mean, you have no foreign keys in your database ?
In SELECT they are definitely useful (think select for update, isolation
level serializable...)
- start quote -
Yo
Hi Richard, thank you for your apreciated answers!!!
- start quote -
Well, do you care whether your data is consistent or
not? If not, you
don't need transactions.
- end quote -
I don't require transaction because the query aren't
complex and update a single tuple (in SELECT
transactions are us
Hi, thanks a lot! you are rigth, but I did read your
message ;)
Yes,
1- I misconfigured PostgreSQL (I thought that was
already configured in base to the released version -
Fedora Core 3 64bit).
2- The bench is, clearly after your precisations, an
MySQL tuned application tests.
3- I think the bench
[EMAIL PROTECTED] (PFC) writes:
>> The reason PostgreSQL is slower is because it (and by extension the team
>> behind it) cares about your data.
>
> Sure, postgres is (a bit but not much) slower for a simple
> query like SELECT * FROM one table WHERE id=some number, and
> postgres is a lot sl
On Wed, 02 Mar 2005 09:00:14 -0600, Scott Marlowe
<[EMAIL PROTECTED]> wrote:
(...)
> The reason PostgreSQL is slower is because it (and by extension the team
> behind it) cares about your data.
>
> Here's a list of the things MySQL will gladly do wrong:
>
> http://sql-info.de/mysql/gotchas.html
This sort of discussion should really go onto -performance, but I'm
at pains to stomp out a common misperception.
On Wed, Mar 02, 2005 at 10:45:38PM +0100, PFC wrote:
>
> Sure, postgres is (a bit but not much) slower for a simple
> query like SELECT * FROM one table WHERE id=some numb
On Wed, 2005-03-02 at 15:45, PFC wrote:
> > The reason PostgreSQL is slower is because it (and by extension the team
> > behind it) cares about your data.
>
> Sure, postgres is (a bit but not much) slower for a simple query like
> SELECT * FROM one table WHERE id=some number, and postgres
The reason PostgreSQL is slower is because it (and by extension the team
behind it) cares about your data.
Sure, postgres is (a bit but not much) slower for a simple query like
SELECT * FROM one table WHERE id=some number, and postgres is a lot slower
for UPDATES (although I heard that it's f
On Tue, 2005-03-01 at 04:52, mauro wrote:
> > Not always, AFAICT. The four most common reasons why PG tests slower
> > than Mysql are:
> > 1. You haven't configured or have misconfigured PostgreSQL.
> > 2. You are testing a MySQL-tuned application (lots of small, simple
> > queries, no views, no
Mauro Bertoli wrote:
Hi Richard, thank you for your apreciated answers!!!
- start quote -
Well, do you care whether your data is consistent or
not? If not, you
don't need transactions.
- end quote -
I don't require transaction because the query aren't
complex and update a single tuple (in SELEC
Mauro Bertoli wrote:
Hi, thanks a lot! you are rigth, but I did read your
message ;)
Yes,
1- I misconfigured PostgreSQL (I thought that was
already configured in base to the released version -
Fedora Core 3 64bit).
2- The bench is, clearly after your precisations, an
MySQL tuned application tests.
mauro wrote:
Not always, AFAICT. The four most common reasons why PG tests slower
than Mysql are:
1. You haven't configured or have misconfigured PostgreSQL.
2. You are testing a MySQL-tuned application (lots of small, simple
queries, no views, no subselects etc)
3. You are only testing one conne
On Tue, Mar 01, 2005 at 02:52:31AM -0800, mauro wrote:
> select_range_key2 89224
> select_range_prefix 89054
> update_of_primary_key_many_keys 20495
These look suspect, especially the first two, and they account for
over 78% of the total. D
> Not always, AFAICT. The four most common reasons why PG tests slower
> than Mysql are:
> 1. You haven't configured or have misconfigured PostgreSQL.
> 2. You are testing a MySQL-tuned application (lots of small, simple
> queries, no views, no subselects etc)
> 3. You are only testing one connec
mauro wrote:
Hi, I understand this is an super-older thread!! note: i like
postgres and not mysql!
Hi Mauro! Whether you like it or hate it, you're in the right place to
ask questions about it.
I'm a Postgres server user: I've postgres 7.2 and 8.0 in many servers
and I've tested performance Postgr
Hi, I understand this is an super-older thread!! note: i like postgres
and not mysql!
I'm a Postgres server user: I've postgres 7.2 and 8.0 in many servers
and I've tested performance Postgres vs MySQL and I see Postgres is
very slow. But my question is: why? Cannot Postgres team make faster
becau
21 matches
Mail list logo
