On Mon, Oct 6, 2014 at 10:53 PM, Tom Lane 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 and resolve those
Heikki Linnakangas 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 it's committable, or
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 pg
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 http://fe
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 reviewe
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
T
> 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 (pgsql-h
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
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 Alva
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 li
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
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 actual
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 in
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 i
"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 o
"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 advantag
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 whateve
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 a
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
"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 talk
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
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 sc
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 blo
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
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
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 misunderstandin
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
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 much
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
"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
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
> wou
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 i
32 matches
Mail list logo
