Samuel Gendler wrote:
I spent some time going through the various tuning docs on the wiki
whie bringing some new hardware up and I can't remember seeing any
discussion of tweaking read-ahead at all in the normal
performance-tuning references. Do you have any documentation of the
kinds of twea
Mladen Gogala wrote:
I agree, but I am afraid that after the demise of SGI, XFS isn't being
developed.
It's back to being well maintained again; see
http://blog.2ndquadrant.com/en/2010/04/the-return-of-xfs-on-linux.html
for some history here and why it's become relevant to RedHat in
particul
On Mon, 11 Oct 2010, Samuel Gendler wrote:
On Mon, Oct 11, 2010 at 9:06 PM, Scott Carey wrote:
I can't speak to documentation, but it is something that helps as your I/O
subsystem gets more powerful, and how much it helps depends more on your
hardware, which may have adaptive read ahead on its
On Mon, Oct 11, 2010 at 9:06 PM, Scott Carey wrote:
> I can't speak to documentation, but it is something that helps as your I/O
> subsystem gets more powerful, and how much it helps depends more on your
> hardware, which may have adaptive read ahead on its own, and your file
> system which may be
I can't speak to documentation, but it is something that helps as your I/O
subsystem gets more powerful, and how much it helps depends more on your
hardware, which may have adaptive read ahead on its own, and your file system
which may be more or less efficient at sequential I/O. For example ex
On Mon, Oct 11, 2010 at 7:19 PM, Greg Smith wrote:
>
>
> This is a problem for the operating system to solve, and such solutions out
> there are already good enough that PostgreSQL has little reason to try and
> innovate in this area. I routinely see seq scan throughput double on Linux
> just by
On Monday 11 October 2010 19:23:46 Mladen Gogala wrote:
> On 10/11/2010 10:02 PM, Scott Carey wrote:
> > Did you tune the linux FS read-ahead first? You can get large gains by
> > doing that if you are on ext3. blockdev --setra 2048
>
> Actually, I have blockdev --setra 32768
>
> > would give
An approach that works can be found in DB2, and likely elsewhere.
The key is that tablespaces/tables/indexes/buffers are all attached through the
bufferpool (the DB2 term). A tablespace/bufferpool match is defined. Then
tables and indexes are assigned to the tablespace (and implicitly, the
On Mon, Oct 4, 2010 at 6:47 PM, Jeremy Harris wrote:
> On 10/04/2010 04:22 AM, Greg Smith wrote:
>>
>> I had a brain-storming session on this subject with a few of the hackers
>> in the community in this area a while back I haven't had a chance to do
>> something with yet (it exists only as a pile
On Monday 11 October 2010 16:50:36 you wrote:
> On 10/11/2010 3:54 PM, Neil Whelchel wrote:
> > 1. A faster count(*), or something like my proposed estimate(*).
> > 2. A way to get the total rows matched when using LIMIT and OFFSET before
> > LIMIT and OFFSET are applied.
>
> The biggest single
On 10/11/2010 10:02 PM, Scott Carey wrote:
Did you tune the linux FS read-ahead first? You can get large gains by doing
that if you are on ext3.
blockdev --setra 2048
Actually, I have blockdev --setra 32768
would give you a 1MB read-ahead. Also, consider XFS and its built-in
defragmentat
On Oct 11, 2010, at 7:02 PM, Scott Carey wrote:
>
> On Oct 10, 2010, at 10:14 AM, Mladen Gogala wrote:
>
>>
>> SQL> show parameter db_file_multi
>>
>> NAME TYPEVALUE
>> ---
>> --
Joshua Tolley wrote:
It was asserted that reading bigger chunks would help performance; a response
suggested that, at least in Linux, setting readahead on a device would
essentially do the same thing. Or that's what I got from the thread, anyway.
I'm interested to know how similar performance mig
On Oct 10, 2010, at 10:14 AM, Mladen Gogala wrote:
>
> SQL> show parameter db_file_multi
>
> NAME TYPEVALUE
> ---
> --
> db_file_multiblock_read_countinteger 16
> SQL> a
On Fri, Oct 1, 2010 at 1:56 AM, Jesper Krogh wrote:
> On 2010-09-30 20:33, Marcelo Zabani wrote:
>>
>> If you can also pinpoint me to where I can find this sort of information
>> (index utilization and planning, performance tuning), I'd be very
>> grateful.
>> Thank you already,
>>
>
> Isn't this
On 10/11/2010 3:54 PM, Neil Whelchel wrote:
1. A faster count(*), or something like my proposed estimate(*).
2. A way to get the total rows matched when using LIMIT and OFFSET before
LIMIT and OFFSET are applied.
The biggest single problem with "select count(*)" is that it is
seriously overus
On Mon, Oct 11, 2010 at 12:54 PM, Neil Whelchel wrote:
>
> 2. You need a slice of the data which requires another scan to the table to
> get, and using the same WHERE clause as above. This seems like a total
> waste,
> because we just did that with the exception of actually fetching the data.
>
>
On Monday 11 October 2010 10:46:17 Craig James wrote:
> On 10/9/10 6:47 PM, Scott Marlowe wrote:
> > On Sat, Oct 9, 2010 at 5:26 PM, Neil Whelchel
wrote:
> >> I know that there haven been many discussions on the slowness of
> >> count(*) even when an index is involved because the visibility of th
> http://www.commandprompt.com/blogs/joshua_drake/2008/04/is_that_performance_i_smell_ext2_vs_ext3_on_50_spindles_testing_for_postgresql/
>
> It doesn't cover XFS but it provides a decent and simple comparison on
> ext2/ext3 etc...
Yeah, it doesn't test actual log writing, though. Nor specific
On Mon, 2010-10-11 at 10:50 -0700, Josh Berkus wrote:
> > There's a number of blog tests floating around comparing XFS and Ext3,
> > and the various Linux schedulers, for PGDATA or for an all-in-one mount.
> >
> > However, the WAL has a rather particular write pattern, and it's
> > reasonable to a
> There's a number of blog tests floating around comparing XFS and Ext3,
> and the various Linux schedulers, for PGDATA or for an all-in-one mount.
>
> However, the WAL has a rather particular write pattern, and it's
> reasonable to assume that it shouldn't be optimized the same way as
> PGDATA.
On 10/9/10 6:47 PM, Scott Marlowe wrote:
On Sat, Oct 9, 2010 at 5:26 PM, Neil Whelchel wrote:
I know that there haven been many discussions on the slowness of count(*) even
when an index is involved because the visibility of the rows has to be
checked. In the past I have seen many suggestions a
I ran into a fine example of this when I was searching this mailing list,
"Searching in 856,646 pages took 13.48202 seconds. Site search powered by
PostgreSQL 8.3." Obviously at some point count(*) came into play here
Well, tsearch full text search is excellent, but it has to work inside the
23 matches
Mail list logo
