From: | Steve <cheetah(at)tanabi(dot)org> |
---|---|
To: | Adam Rich <adam(dot)r(at)sbcglobal(dot)net> |
Cc: | "'Bricklen Anderson'" <banderson(at)presinet(dot)com>, pgsql-performance(at)postgresql(dot)org |
Subject: | Re: Configuration Advice |
Date: | 2007-01-18 00:32:34 |
Message-ID: | Pine.GSO.4.64.0701171927450.4471@kingcheetah.tanabi.org |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-performance |
This would probably also be another last ditch option. :) Our stuff is
designed to pretty much work on any DB but there are postgres specific
things in there... not to mention ramp up time on MySQL. I mean, I know
MySQL from a user point of view and in a very limited way
administratively, but I'd be back to square one on learning performance
stuff :)
Anyway -- I'll listen to what people have to say, and keep this in mind.
It would be an interesting test to take parts of the process and compare
at least, if not converting the whole thing.
talk to you later,
Steve
On Wed, 17 Jan 2007, Adam Rich wrote:
>
> Sorry if this came off sounding trollish.... All databases have their
> strengths & weaknesses, and I feel the responsible thing to do is
> exploit
> those strengths where possible, rather than expend significant time and
> effort coaxing one database to do something it wasn't designed to.
> There's just no such thing as "one size fits all".
>
> I have professional experience with MS-SQL, Oracle, MySQL, and Postgres.
> and the scenario described sounds more ideal for MySQL & MyISAM than
> anything else:
>
> 1) No concerns for data loss (turning fsync & full_page_writes off)
> since the data can be reloaded
>
> 2) No need for MVCC or transactions, since the database is read-only
>
> 3) No worries about lock contention
>
> 4) Complex queries that might take advantage of the MySQL "Query Cache"
> since the base data never changes
>
> 5) Queries that might obtain data directly from indexes without having
> to touch tables (again, no need for MVCC)
>
> If loading in the base data and creating the summary table is taking
> a lot of time, using MySQL with MyISAM tables (and binary logging
> disabled) should provide significant time savings, and it doesn't
> sound like there's any concerns for the downsides.
>
> Yes, postgresql holds an edge over MySQL for heavy OLTP applications,
> I use it for that and I love it. But for the scenario the original
> poster is asking about, MySQL/MyISAM is ideal.
>
>
>
>
> -----Original Message-----
> From: Bricklen Anderson [mailto:banderson(at)presinet(dot)com]
> Sent: Wednesday, January 17, 2007 3:29 PM
> To: Adam Rich
> Cc: pgsql-performance(at)postgresql(dot)org
> Subject: Re: [PERFORM] Configuration Advice
>
>
> Adam Rich wrote:
>> Doesn't sound like you want postgres at all.... Try mysql.
>
> Could you explain your reason for suggesting mysql? I'm simply curious
> why you would offer that as a solution.
>
>
> ---------------------------(end of broadcast)---------------------------
> TIP 9: In versions below 8.0, the planner will ignore your desire to
> choose an index scan if your joining column's datatypes do not
> match
>
From | Date | Subject | |
---|---|---|---|
Next Message | Steve | 2007-01-18 00:50:11 | Re: Configuration Advice |
Previous Message | Steve | 2007-01-18 00:27:22 | Re: Configuration Advice |