Mark Kirkwood wrote:
Yeah, RHEL6 seems like the version we would prefer - unfortunately
time frame is the next few days. Awesome - thanks for the quick reply!
The RHEL6 beta is out, I'm running it, and I expect a straightforward
upgrade path to the final release--I think I can just keep grabbi
On 02/06/10 17:17, Devrim GÜNDÜZ wrote:
For xfs, you may want to read this:
http://blog.2ndquadrant.com/en/2010/04/the-return-of-xfs-on-linux.html
Thanks - yes RHEL6 is the version we would have liked to use I suspect!
Regards
Mark
--
Sent via pgsql-performance mailing list (pgsql-p
On Wed, 2010-06-02 at 15:06 +1200, Mark Kirkwood wrote:
> What are Red Hat using people choosing for a good performing
> filesystem?
ext2 (xlogs) and ext3 (data).
For xfs, you may want to read this:
http://blog.2ndquadrant.com/en/2010/04/the-return-of-xfs-on-linux.html
Regards,
--
Devrim GÜND
On 02/06/10 15:26, Tom Lane wrote:
What's your time horizon? RHEL6 will have full support for xfs.
On RHEL5 I really wouldn't consider anything except ext3.
Yeah, RHEL6 seems like the version we would prefer - unfortunately time
frame is the next few days. Awesome - thanks for the quick r
Mark Kirkwood writes:
> I'm helping set up a Red Hat 5.5 system for Postgres. I was going to
> recommend xfs for the filesystem - however it seems that xfs is
> supported as a technology preview "layered product" for 5.5. This
> apparently means that the xfs tools are only available via special
I'm helping set up a Red Hat 5.5 system for Postgres. I was going to
recommend xfs for the filesystem - however it seems that xfs is
supported as a technology preview "layered product" for 5.5. This
apparently means that the xfs tools are only available via special
channels.
What are Red Hat
Excerpts from David Jarvis's message of mar jun 01 14:01:22 -0400 2010:
> Sorry, Alvaro.
>
> I was contemplating using a GIN or GiST index as a way of optimizing the
> query.
My fault -- I didn't read the whole thread.
> Instead, I found that re-inserting the data in order of station ID (the
> p
Excerpts from Matthew Wakeling's message of mar jun 01 05:55:35 -0400 2010:
> On Sun, 23 May 2010, David Jarvis wrote:
> > The measurement table indexes (on date and weather station) were not being
> > used because the only given date ranges (e.g., 1900 - 2009) were causing the
> > planner to do a
On Tue, Jun 1, 2010 at 8:59 AM, Matthew Wakeling wrote:
> On Tue, 1 Jun 2010, Stephen Frost wrote:
>>
>> * Matthew Wakeling (matt...@flymine.org) wrote:
>>>
>>> The major case I found when writing pl/pgsql was when trying to build
>>> arrays row by row. AFAIK when I tried it, adding a row to an ar
Scott Carey writes:
> It is still best to have random_page_cost to be slightly larger (~50%)
> than sequential_page_cost, because even when entirely in RAM,
> sequential reads are faster than random reads. Today's CPU's do
> memory prefetching on sequential access.
Do you have any actual evidenc
On Tue, 2010-06-01 at 10:27 +0300, Mindaugas Riauba wrote:
> Hello,
>
> >>> Anybody on the list have any experience with these drives? They get
> >>> good numbers but I can't find diddly on them on the internet for the
> >>> last year or so.
> >>>
> >>> http://www.stec-inc.com/product/zeusiops.ph
On Tue, 1 Jun 2010, Stephen Frost wrote:
* Matthew Wakeling (matt...@flymine.org) wrote:
The major case I found when writing pl/pgsql was when trying to build
arrays row by row. AFAIK when I tried it, adding a row to an array caused
the whole array to be copied, which put a bit of a damper on pe
* Matthew Wakeling (matt...@flymine.org) wrote:
> The major case I found when writing pl/pgsql was when trying to build
> arrays row by row. AFAIK when I tried it, adding a row to an array caused
> the whole array to be copied, which put a bit of a damper on performance.
Using the built-ins now
On Fri, 28 May 2010, Merlin Moncure wrote:
At best, if you are a ninja with the marginally documented backend
api, you will create code that goes about as fast as your pl/pgsql
function for 10 times the amount of input work, unless there are heavy
amounts of 'other than sql' code in your function
On Sun, 23 May 2010, David Jarvis wrote:
The measurement table indexes (on date and weather station) were not being
used because the only given date ranges (e.g., 1900 - 2009) were causing the
planner to do a full table scan, which is correct.
I wonder if you might see some benefit from CLUSTER
Hello,
>>> Anybody on the list have any experience with these drives? They get
>>> good numbers but I can't find diddly on them on the internet for the
>>> last year or so.
>>>
>>> http://www.stec-inc.com/product/zeusiops.php
Most of the storage vendors (I have confirmation from EMC and HP)
It is still best to have random_page_cost to be slightly larger (~50%) than
sequential_page_cost, because even when entirely in RAM, sequential reads are
faster than random reads. Today's CPU's do memory prefetching on sequential
access. Perhaps try something like 0.3 and 0.2, or half that. Y
17 matches
Mail list logo
