Skip site navigation (1) Skip section navigation (2)

Re: Commitfest patches

From: Gregory Stark <stark(at)enterprisedb(dot)com>
To: "Bruce Momjian" <bruce(at)momjian(dot)us>
Cc: "Pg Hackers" <pgsql-hackers(at)postgresql(dot)org>
Subject: Re: Commitfest patches
Date: 2008-03-28 17:34:30
Message-ID: (view raw, whole thread or download thread mbox)
Lists: pgsql-hackers
"Bruce Momjian" <bruce(at)momjian(dot)us> writes:

> Gregory Stark wrote:
>> Bruce, you seem to have removed one of my three patches from the queue. I
>> would actually prefer you remove the other two and put back that one. It's the
>> one I most urgently need feedback on to continue.
> I talked to Greg on IM.  The complaint was that his posix_fadvise()
> patch was added to the TODO list as a URL, rather than getting him
> feedback.  He is getting feedback now in another thread.

Sort of. The feedback I'm getting is from people who want to discuss the
"easy" parameters of the patch like how much prefetching to do and when
without actually reading to see what's already been done. I'm happy to discuss
them as I find these things interesting too.

But what I really need is someone to read the patch and say "looks good" or
point out things they don't like. In particular, what I really, really want is
some guidance on the singular key question I asked.

I want to know if we're interested in the more invasive patch restructuring
the buffer manager. My feeling is that we probably are eventually. But I
wonder if people wouldn't feel more comfortable taking baby steps at first
which will have less impact in cases where it's not being heavily used.

It's a lot more work to do the invasive patch and there's not much point in
doing it if we're not interested in taking it when it's ready.

Here's an updated patch. It's mainly just a CVS update but it also includes
some window dressing: an autoconf test, some documentation, and some fancy
arithmetic to auto-tune the amount of prefetching based on a more real-world
parameter "effective_spindle_count". It also includes printing out how much
the prefetching target got ramped up to in the explain output -- though I'm
not sure we really want that in the tree, but it's nice for performance

Attachment: bitmap-preread-v9.diff.gz
Description: application/octet-stream (9.1 KB)

In response to


pgsql-hackers by date

Next:From: Tomas DoranDate: 2008-03-28 17:58:33
Subject: Re: [PATCHES] Implemented current_query
Previous:From: Gregory StarkDate: 2008-03-28 17:24:15
Subject: Re: Prereading using posix_fadvise

Privacy Policy | About PostgreSQL
Copyright © 1996-2018 The PostgreSQL Global Development Group