In addition to the few patches left in Needs Review state, we have six
patches marked as Ready for Committer.
Committers: Could you please pick a patch, and commit if appropriate? Or
if there's a patch there that you think should *not* be committed,
please speak up.
- Heikki
--
Sent via
Heikki Linnakangas hlinnakan...@vmware.com writes:
Committers: Could you please pick a patch, and commit if appropriate? Or
if there's a patch there that you think should *not* be committed,
please speak up.
The custom plan API thing may be marked ready for committer, but that
doesn't mean
On Mon, Oct 6, 2014 at 10:53 PM, Tom Lane t...@sss.pgh.pa.us wrote:
The levenshtein-distance thingy seems to still be a topic of debate
as well, both as to how we're going to refactor the code and as to
what the exact hinting rules ought to be. If some committer wants
to take charge of it
Folks,
When you update a patch, please make sure to let your reviewer(s) know
you have in addition to putting it in the Commitfest application.
This will help ensure that your patch moves along its track to a
satisfactory outcome for all this Commitfest.
Cheers,
David.
--
David Fetter
Josh Berkus wrote:
Hackers,
At this point, almost all patches have been assigned to reviewers. If
you submitted a patch and don't get feedback by Saturday, take a look at
who's in the reviewers column and send them a query. Since I have no
way to track when patches are assigned to
Josh Berkus [EMAIL PROTECTED] writes:
Also, note that the following patches need performance testing on a
variety of platforms. Everyone should help with this.
GSoC Improved Hash Indexing
posix fadvises
operator restrictivity function for text search
CLUSTER using sort instead of index
On Thu, Sep 11, 2008 at 1:53 AM, Josh Berkus [EMAIL PROTECTED] wrote:
Some patches have not been assigned to reviewers for various reasons. The
following weren't assigned because they are complex and really need a
high-end hacker or committer to take them on:
libpq events
Alvaro actually
Merlin Moncure escribió:
On Thu, Sep 11, 2008 at 1:53 AM, Josh Berkus [EMAIL PROTECTED] wrote:
Some patches have not been assigned to reviewers for various reasons. The
following weren't assigned because they are complex and really need a
high-end hacker or committer to take them on:
Alvaro Herrera wrote:
Actually a minor gripe ... should PQsetvalue be PQsetValue? :-)
We were mimicing PQgetvalue, which uses a lowercase 'v'. Is there a
preference, none on this end.
--
Andrew Chernow
eSilo, LLC
every bit counts
http://www.esilo.com/
--
Sent via pgsql-hackers mailing
Alvaro Herrera [EMAIL PROTECTED] writes:
Merlin Moncure escribió:
Alvaro actually performed a review on libpq events. We are waiting on
his feedback on our changes (based on his review) and the newly
submitted documentation. I'll update the wiki accordingly. I wasn't
sure if Alvaro was
On Thu, Sep 11, 2008 at 5:06 PM, Tom Lane [EMAIL PROTECTED] wrote:
The patch looks OK to me as it was the last time I looked at it; maybe
Tom has more comments, so I decided against just committing it.
I haven't got round to looking at it in this fest. If anyone else wants
to look it over,
Josh is probably basing that on the long history of
discussion/revision cycles.
Yep, and that *I* don't understand what the patch does, so I'm not going to
turn a newbie reviewer loose on it.
--
--Josh
Josh Berkus
PostgreSQL
San Francisco
--
Sent via pgsql-hackers mailing list
Josh Berkus wrote:
Josh is probably basing that on the long history of
discussion/revision cycles.
Yep, and that *I* don't understand what the patch does, so I'm not going to
turn a newbie reviewer loose on it.
Here is a quick overview, there are two parts to the patch:
1. event system
Hackers,
At this point, almost all patches have been assigned to reviewers. If
you submitted a patch and don't get feedback by Saturday, take a look at
who's in the reviewers column and send them a query. Since I have no
way to track when patches are assigned to reviewers, I have no idea if
Martijn van Oosterhout [EMAIL PROTECTED] writes:
- I think normal index scans could benefit from this (it was measurable
when I was playing with AIO in postgres a few years back).
I don't want to torture any existing code paths to get prefetching to work.
Heikki suggested I take advantage of
Greg Smith [EMAIL PROTECTED] writes:
On Fri, 28 Mar 2008, Gregory Stark wrote:
I described which interfaces worked on Linux and Solaris based on empirical
tests. I posted source code for synthetic benchmarks so we could test it on a
wide range of hardware. I posted graphs based on empirical
On Fri, 28 Mar 2008, Gregory Stark wrote:
I described which interfaces worked on Linux and Solaris based on empirical
tests. I posted source code for synthetic benchmarks so we could test it on a
wide range of hardware. I posted graphs based on empirical results.
Is it possible to post
On Fri, 2008-03-28 at 09:08 +, Gregory Stark wrote:
A more invasive form of this patch would be to assign and pin a buffer when
the preread is done. That would men subsequently we would have a pinned buffer
ready to go and not need to go back to the buffer manager a second time. We
would
Simon Riggs [EMAIL PROTECTED] writes:
On Fri, 2008-03-28 at 09:08 +, Gregory Stark wrote:
A more invasive form of this patch would be to assign and pin a buffer when
the preread is done. That would men subsequently we would have a pinned
buffer
ready to go and not need to go back to
On Fri, 2008-03-28 at 11:26 +, Gregory Stark wrote:
Simon Riggs [EMAIL PROTECTED] writes:
For heaven's sake. I've been posting about this for months.
Any chance of getting all that together on a single Wiki page, so we can
review everything? We'll need those docs after its committed
Gregory Stark wrote:
I described which interfaces worked on Linux and Solaris based on empirical
tests. I posted source code for synthetic benchmarks so we could test it on a
wide range of hardware. I posted graphs based on empirical results. I posted
mathematical formulas analysing just how
Heikki wrote:
It seems that the worst case for this patch is a scan on a table that
doesn't fit in shared_buffers, but is fully cached in the OS cache. In
that case, the posix_fadvise calls would be a certain waste of time.
I think this is a misunderstanding, the fadvise is not issued to
Zeugswetter Andreas OSB SD wrote:
Heikki wrote:
It seems that the worst case for this patch is a scan on a table that
doesn't fit in shared_buffers, but is fully cached in the OS cache. In
that case, the posix_fadvise calls would be a certain waste of time.
I think this is a
Heikki Linnakangas wrote:
So it has nothing to do with table size. The fadvise calls need to be
(and are)
limited by what can be used in the near future, and not for the whole
statement.
Right, I was sloppy. Instead of table size, what matters is the amount
of data the scan needs to
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()
On Fri, Mar 28, 2008 at 11:41:58AM -0400, Bruce Momjian wrote:
Should we consider only telling the kernel X pages ahead, meaning when
we are on page 10 we tell it about page 16?
It's not so interesting for sequential reads, the kernel can work that
out for itself. Disk reads are usually in
Bruce Momjian wrote:
Heikki Linnakangas wrote:
So it has nothing to do with table size. The fadvise calls need to be
(and are)
limited by what can be used in the near future, and not for the whole
statement.
Right, I was sloppy. Instead of table size, what matters is the amount
of data the
Heikki Linnakangas wrote:
Should we consider only telling the kernel X pages ahead, meaning when
we are on page 10 we tell it about page 16?
Yes. You don't want to fire off thousands of posix_fadvise calls
upfront. That'll just flood the kernel, and it will most likely ignore
any advise
Bruce Momjian [EMAIL PROTECTED] 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
Gregory Stark wrote:
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
On Fri, Mar 28, 2008 at 05:34:30PM +, Gregory Stark wrote:
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 was going to write all
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.
The patch I'm so interested in receiving feedback on is the patch to preread
pages in bitmap
32 matches
Mail list logo
