On Fri, 3 Oct 2003, Bruce Momjian wrote:
>
> I have updated the FAQ to be:
>
> In comparison to MySQL or leaner database systems, we are
> faster for multiple users, complex queries, and a read/write query
> load. MySQL is faster for SELECT queries done by a few users.
>
> Is th
Rod Taylor <[EMAIL PROTECTED]> writes:
> I've often wondered if they win on those because they have a lighter
> weight parser / optimizer with less "lets try simplifying this query"
> steps or if the MYISAM storage mechanism is simply quicker at pulling
> data off the disk.
Comparing pre-PREPAREd
Centuries ago, Nostradamus foresaw when [EMAIL PROTECTED] (Bruce Momjian) would write:
> I have updated the FAQ to be:
>
> In comparison to MySQL or leaner database systems, we are
> faster for multiple users, complex queries, and a read/write query
> load. MySQL is faster for SE
Rod Taylor wrote:
-- Start of PGP signed section.
> On Fri, 2003-10-03 at 21:39, Bruce Momjian wrote:
> > I have updated the FAQ to be:
> >
> > In comparison to MySQL or leaner database systems, we are
> > faster for multiple users, complex queries, and a read/write query
> > loa
On Fri, 2003-10-03 at 21:39, Bruce Momjian wrote:
> I have updated the FAQ to be:
>
> In comparison to MySQL or leaner database systems, we are
> faster for multiple users, complex queries, and a read/write query
> load. MySQL is faster for SELECT queries done by a few users.
>
m: Jeff [mailto:[EMAIL PROTECTED]
> Sent: Wednesday, October 01, 2003 6:23 AM
> To: David Griffiths
> Cc: [EMAIL PROTECTED]
> Subject: Re: [PERFORM] Tuning/performance issue...
> Importance: Low
>
>
> On Tue, 30 Sep 2003, David Griffiths wrote:
>
> >
> > This i
That would be great! When do you think this would be ready for us to see
;?)
-Original Message-
From: Jeff [mailto:[EMAIL PROTECTED]
Sent: Wednesday, October 01, 2003 11:42 AM
To: Oleg Lebedev
Cc: [EMAIL PROTECTED]
Subject: RE: [PERFORM] Tuning/performance issue...
On Wed, 1 Oct 2003
On Wed, 1 Oct 2003, Oleg Lebedev wrote:
> Jeff,
> I would really appreciate if you could send me that lengthy presentation
> that you've written on pg/other dbs comparison.
> Thanks.
>
After I give the presentation at work and collect comments from my
coworkers (and remove some information you fo
bject: Re: [PERFORM] Tuning/performance issue...
Importance: Low
On Tue, 30 Sep 2003, David Griffiths wrote:
>
> This is all part of a "migrate away from Oracle" project. We are
> looking at 3 databases - MySQL (InnoDB), Postgres and Matisse (object
> oriented). We hav
David Griffiths <[EMAIL PROTECTED]> writes:
>> The reason PG's planner doesn't discover this join order for itself
>> is that it's written to not attempt to re-order outer joins from the
>> syntactically defined ordering. In general, such reordering would
>> change the results. It is possible to
On Tue, 30 Sep 2003, David Griffiths wrote:
>
> This is all part of a "migrate away from Oracle" project. We are looking at
> 3 databases -
> MySQL (InnoDB), Postgres and Matisse (object oriented). We have alot of
> queries like this
> or worse, and I'm worried that many of them would need to be r
David Griffiths wrote:
And finally,
Here's the contents of the postgresql.conf file (I've been playing with
these setting the last couple of days, and using the guide @
http://www.varlena.com/varlena/GeneralBits/Tidbits/annotated_conf_e.html to
make sure I didn't have it mis-tuned):
tcpip_s
> The most efficient way to handle this query would probably be to join
> the three tables with restrictions first, and then join the other tables
> to those. You could force this with not too much rewriting using
> something like (untested, but I think it's right)
>
> ... FROM commercial_entity C
David Griffiths <[EMAIL PROTECTED]> writes:
> ... FROM commercial_entity, country, user_account,
> address_list LEFT JOIN state_province ON address_list.state_province_id
> = state_province.state_province_id
> LEFT JOIN contact_info ON address_list.contact_info_id =
> contact_info.contact_info_id
>
14 matches
Mail list logo
