On Fri, Sep 15, 2017 at 8:13 AM, Robert Haas wrote:
> On Wed, Sep 13, 2017 at 5:18 AM, Alvaro Herrera
> wrote:
>> Thinking further, I think changing patch status automatically may never
>> be a good idea; there's always going to be some amount of common sense
>> applied beforehand (such as if a
On Wed, Sep 13, 2017 at 5:18 AM, Alvaro Herrera wrote:
> Thinking further, I think changing patch status automatically may never
> be a good idea; there's always going to be some amount of common sense
> applied beforehand (such as if a conflict is just an Oid catalog
> collision, or a typo fix in
Hi Martin,
> > === Build Failed: 7 ===
> > Title: Fix the optimization to skip WAL-logging on table created in same
> > transaction
> > Author: Martijn van Oosterhout
> > URL: https://commitfest.postgresql.org/14/528/
>
> I'm not the author of this patch, and the page doesn't say so.
> Somethin
Hi Aleksander,
On 09/13/2017 11:49 AM, Aleksander Alekseev wrote:
> Hi Tomas,
>
> I appreciate your feedback, although it doesn't seem to be completely
> fair. Particularly:
>
>> You gave everyone about 4 hours to object
>
> This is not quite accurate since my proposal was sent 2017-09-11
> 09:
> On 13 Sep 2017, at 11:49, Aleksander Alekseev
> wrote:
>
> Hi Tomas,
>
> I appreciate your feedback, although it doesn't seem to be completely
> fair.
I would like to stress one thing (and I am speaking only for myself here), this
has been feedback and not criticism. Your (and everyone invo
Hi Tomas,
I appreciate your feedback, although it doesn't seem to be completely
fair. Particularly:
> You gave everyone about 4 hours to object
This is not quite accurate since my proposal was sent 2017-09-11
09:41:32 and this thread started - 2017-09-12 14:14:55.
> You just changed the status
Aleksander Alekseev wrote:
> Agree, especially regarding build logs. All of this currently is only an
> experiment. For some reason I got a weird feeling that at this time it
> will be not quite successful one. If there will be too many false
> positives I'll just return the patches back to "Needs
Hello, aside from the discussion on the policy of usage of
automation CI, it seems having trouble applying patches.
https://travis-ci.org/postgresql-cfbot/postgresql/builds/27450
>1363 heapam.c:2502:18: error: ‘HEAP_INSERT_SKIP_WAL’ undeclared (first use in
>this function)
>1364 if (!(optio
At Wed, 13 Sep 2017 08:13:08 +0900, Michael Paquier
wrote in
> On Wed, Sep 13, 2017 at 7:39 AM, Daniel Gustafsson wrote:
> >> On 12 Sep 2017, at 23:54, Tomas Vondra
> >> wrote:
> >> With all due respect, it's hard not to see this as a disruption of the
> >> current CF. I agree automating the
On Wed, Sep 13, 2017 at 7:39 AM, Daniel Gustafsson wrote:
>> On 12 Sep 2017, at 23:54, Tomas Vondra wrote:
>> With all due respect, it's hard not to see this as a disruption of the
>> current CF. I agree automating the patch processing is a worthwhile
>> goal, but we're not there yet and it seems
> On 12 Sep 2017, at 23:54, Tomas Vondra wrote:
>
> On 09/12/2017 04:14 PM, Aleksander Alekseev wrote:
>> Hello, hackers!
>>
>> Thanks to the work of Thomas Munro now we have a CI for the patches on
>> the commitfest [1]. Naturally there is still room for improvement, but
>> in any case it's muc
On 09/12/2017 04:14 PM, Aleksander Alekseev wrote:
> Hello, hackers!
>
> Thanks to the work of Thomas Munro now we have a CI for the patches on
> the commitfest [1]. Naturally there is still room for improvement, but
> in any case it's much, much better than nothing.
>
> After a short discussion
On Wed, Sep 13, 2017 at 2:55 AM, Andreas Karlsson wrote:
> On 09/12/2017 04:14 PM, Aleksander Alekseev wrote:
>>
>> Title: Foreign Key Arrays
>> Author: Mark Rofail
>> URL:https://commitfest.postgresql.org/14/1252/
>
>
> I am currently reviewing this one and it applies, compiles, and passes the
>
Hi Andreas,
On 09/12/2017 04:14 PM, Aleksander Alekseev wrote:
> > Title: Foreign Key Arrays
> > Author: Mark Rofail
> > URL:https://commitfest.postgresql.org/14/1252/
>
> I am currently reviewing this one and it applies, compiles, and passes the
> test suite. It could be the compilation warnings
On 09/12/2017 04:14 PM, Aleksander Alekseev wrote:
Title: Foreign Key Arrays
Author: Mark Rofail
URL:https://commitfest.postgresql.org/14/1252/
I am currently reviewing this one and it applies, compiles, and passes
the test suite. It could be the compilation warnings which makes the
system th
Hello, hackers!
Thanks to the work of Thomas Munro now we have a CI for the patches on
the commitfest [1]. Naturally there is still room for improvement, but
in any case it's much, much better than nothing.
After a short discussion [2] we agreed (or at least no one objected) to
determine the patc
On Sun, Aug 13, 2017 at 11:43 PM, Robert Haas wrote:
> On Sun, Aug 13, 2017 at 5:24 PM, Tom Lane wrote:
> >> I'd vote for including this in v10. There doesn't seem to be any
> >> downside to this: it's a no brainer to avoid our exploding hash table
> >> case when we can see it coming.
> >
> > A
On 2017-08-13 17:43:10 -0400, Robert Haas wrote:
> On Sun, Aug 13, 2017 at 5:24 PM, Tom Lane wrote:
> >> I'd vote for including this in v10. There doesn't seem to be any
> >> downside to this: it's a no brainer to avoid our exploding hash table
> >> case when we can see it coming.
> >
> > Anybody
On Sun, Aug 13, 2017 at 5:24 PM, Tom Lane wrote:
>> I'd vote for including this in v10. There doesn't seem to be any
>> downside to this: it's a no brainer to avoid our exploding hash table
>> case when we can see it coming.
>
> Anybody else want to vote that way? For myself it's getting a bit l
Thomas Munro writes:
> On Sat, Aug 12, 2017 at 3:24 AM, Tom Lane wrote:
>> 1. check-hash-bucket-size-against-work_mem-2.patch from
>> https://www.postgresql.org/message-id/13698.1487283...@sss.pgh.pa.us
> +1
> I'd vote for including this in v10. There doesn't seem to be any
> downside to this:
On 13/08/17 16:19, Thomas Munro wrote:
On Sat, Aug 12, 2017 at 3:24 AM, Tom Lane wrote:
[...]
I'd vote for including this in v10. There doesn't seem to be any
downside to this: it's a no brainer to avoid our exploding hash table
case when we can see it coming.
But explosions are fun!
< duc
On Sat, Aug 12, 2017 at 3:24 AM, Tom Lane wrote:
> I have some patches sitting around in my workspace that I think are
> non-controversial, and so I was considering just pushing them once
> the tree opens for v11 development. If anyone thinks they need
> further review, I'll put them into the Sep
Robert Haas writes:
> On Fri, Aug 11, 2017 at 11:24 AM, Tom Lane wrote:
>> 3. remove-pgbench-option-ordering-constraint.patch from
>> https://www.postgresql.org/message-id/20559.1501703...@sss.pgh.pa.us
>>
>> That one was already informally reviewed by two people, so I don't
>> think it needs an
On Fri, Aug 11, 2017 at 11:24 AM, Tom Lane wrote:
> 3. remove-pgbench-option-ordering-constraint.patch from
> https://www.postgresql.org/message-id/20559.1501703...@sss.pgh.pa.us
>
> That one was already informally reviewed by two people, so I don't
> think it needs another look.
I'd vote for put
I have some patches sitting around in my workspace that I think are
non-controversial, and so I was considering just pushing them once
the tree opens for v11 development. If anyone thinks they need
further review, I'll put them into the September commitfest, but
otherwise we might as well skip the
On Mon, Jan 28, 2013 at 8:39 AM, Heikki Linnakangas
wrote:
> On 15.01.2013 21:03, Tom Lane wrote:
>> Robert Haas writes:
>>>
>>> On the third hand, the fact that a table is OCDR is recorded in
>>> backend-local storage somewhere, and that storage (unlike the
>>> relcache) had better be reliable.
Robert Haas writes:
> On the third hand, the fact that a table is OCDR is recorded in
> backend-local storage somewhere, and that storage (unlike the
> relcache) had better be reliable. So maybe there's some way to
> finesse it that way.
Hm, keep a flag in that storage you mean? Yeah, that coul
On Tue, Jan 15, 2013 at 10:57 AM, Tom Lane wrote:
> Gurjeet Singh writes:
>> On Mon, Jan 14, 2013 at 10:33 PM, Tom Lane wrote:
>>> I think this is unacceptable on its face. It essentially supposes that
>>> relcache entries are reliable storage. They are not.
>
>> Would it be acceptable if we i
Gurjeet Singh writes:
> On Mon, Jan 14, 2013 at 10:33 PM, Tom Lane wrote:
>> I think this is unacceptable on its face. It essentially supposes that
>> relcache entries are reliable storage. They are not.
> Would it be acceptable if we inverted the meaning of the struct member, and
> named it t
On Mon, Jan 14, 2013 at 10:33 PM, Tom Lane wrote:
> Gurjeet Singh writes:
> > Please find attached two patches, implementing two different approaches
> to
> > fix the issue of COMMIT truncating empty TEMP tables that have the ON
> > COMMIT DELETE ROWS attribute.
>
> > v2.patch: This approach int
Gurjeet Singh writes:
> Please find attached two patches, implementing two different approaches to
> fix the issue of COMMIT truncating empty TEMP tables that have the ON
> COMMIT DELETE ROWS attribute.
> v2.patch: This approach introduces a boolean 'rd_rows_inserted' in
> RelationData struct, an
On Wed, Feb 9, 2011 at 1:45 PM, Robert Haas wrote:
> A few other ones that could use more reviewers include:
I've just corrected the status of a few patches in the CommitFest
application. In particular, I set the following back to Needs Review.
SQL/MED - postgresql_fdw
Self-tuning checkpoint sy
[Cc: trimmed]
On Wed, Feb 09, 2011 at 01:45:11PM -0500, Robert Haas wrote:
> A few other ones that could use more reviewers include:
> key locks
I'll take a look at this one.
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.
--On 9. Februar 2011 13:45:11 -0500 Robert Haas
wrote:
Of the fourteen I signed up for, 10 are now marked Committed or
Returned with Feedback. Of the remaining four, there are two that
could use more eyes:
I'd happily jump in and look into one of those, but before mid of next week
i rea
* Robert Haas (robertmh...@gmail.com) wrote:
> Of the fourteen I signed up for, 10 are now marked Committed or
> Returned with Feedback. Of the remaining four, there are two that
> could use more eyes:
>
> MULTISET functions
I'll work on this one.
> Change pg_last_xlog_receive_location not to m
On Wed, Feb 9, 2011 at 1:35 PM, Stephen Frost wrote:
> * Robert Haas (robertmh...@gmail.com) wrote:
>> On Wed, Feb 9, 2011 at 1:09 PM, David E. Wheeler
>> wrote:
>> > Frankly, I think you should surrender some of those 14 and cajole some
>> > other folks to take on more.
>>
>> Happily... only
On Thu, 2009-10-29 at 09:32 -0400, Tom Lane wrote:
> Hannu Krosing writes:
> > Or maybe we could just extract the hashes form some version of stock
> > postgresql (say 8.3) and then make those available in contrib under the
> > name "stable_hashes" ?
>
> A better name would be "wishful_thinking"
On Thu, 2009-10-29 at 09:32 -0400, Tom Lane wrote:
> Hannu Krosing writes:
> > Or maybe we could just extract the hashes form some version of stock
> > postgresql (say 8.3) and then make those available in contrib under the
> > name "stable_hashes" ?
>
> A better name would be "wishful_thinking"
Hannu Krosing writes:
> Or maybe we could just extract the hashes form some version of stock
> postgresql (say 8.3) and then make those available in contrib under the
> name "stable_hashes" ?
A better name would be "wishful_thinking" ... contrib does not have
control over some of the main risk fa
On Thu, 2009-10-29 at 09:47 +0200, Peter Eisentraut wrote:
> On Wed, 2009-10-28 at 12:51 -0700, Jeff Davis wrote:
> > Trying to develop and document a set of standardized, stable hash
> > functions covering a wide range of possible use cases sounds like it may
> > be better served by an extension.
On Wed, 2009-10-28 at 12:51 -0700, Jeff Davis wrote:
> Trying to develop and document a set of standardized, stable hash
> functions covering a wide range of possible use cases sounds like it may
> be better served by an extension.
I suspect that some of the participants in this thread have PL/Pro
On Wed, 2009-10-28 at 15:31 -0400, Tom Lane wrote:
> Hannu Krosing writes:
> > I had never checked the docs for hash functions, but I had assumed, that
> > internal functions are prefixed by pg_ and anything else is public, free
> > to use functionality.
>
> Sure, it's free to use. It's not free
On Wed, 2009-10-28 at 12:51 -0700, Jeff Davis wrote:
> On Wed, 2009-10-28 at 21:09 +0200, Hannu Krosing wrote:
> > Is at least the fact that they "are undocumented, have changed in the
> > past, and are likely to change again in the future" documented ?
>
> That's a little confusing to me: how do
On Wed, 2009-10-28 at 21:09 +0200, Hannu Krosing wrote:
> Is at least the fact that they "are undocumented, have changed in the
> past, and are likely to change again in the future" documented ?
That's a little confusing to me: how do we document that something is
undocumented? And where do we sto
Kenneth Marshall writes:
> On Wed, Oct 28, 2009 at 03:31:17PM -0400, Tom Lane wrote:
>> Hash indexes are so far from being production-grade that this argument
>> is not significant.
> In addition that change from 8.3 -> 8.4 to store only the hash and not
> the value in the index means that a rein
On Wed, Oct 28, 2009 at 03:31:17PM -0400, Tom Lane wrote:
> Hannu Krosing writes:
> > I had never checked the docs for hash functions, but I had assumed, that
> > internal functions are prefixed by pg_ and anything else is public, free
> > to use functionality.
>
> Sure, it's free to use. It's n
Hannu Krosing writes:
> I had never checked the docs for hash functions, but I had assumed, that
> internal functions are prefixed by pg_ and anything else is public, free
> to use functionality.
Sure, it's free to use. It's not free to assume that we promise never
to change it.
> Changing hash
On Wed, 2009-02-11 at 11:22 -0500, Tom Lane wrote:
> Asko Oja writes:
> > Did this change hashtext() visible to users? We have been using it quite
> > widely for partitioning our databases. If so then it should be marked quite
> > visibly in release notes as there might be others who will be hit b
Tom Lane wrote:
> I've applied the first three of these changes, but not the last two
> (the 'dist' assignments). "clang" seems to have a tin ear for style :-(.
> It's failing to notice that we have several similar code blocks in
> sequence in these two places, and making the last one different fr
Paul Matthews writes:
> Grzegorz Jaskiewicz wonderful static checker coughed up 5 errors in
> geo_ops.c. None of them of any particular excitement or of earth
> shattering nature. A patch is attached below that should correct these.
> (The more little issue we eliminate, the more the large ones w
On 27 Aug 2009, at 10:46, Paul Matthews wrote:
Grzegorz Jaskiewicz wonderful static checker coughed up 5 errors in
geo_ops.c. None of them of any particular excitement or of earth
shattering nature. A patch is attached below that should correct
these.
(The more little issue we eliminate, the
Grzegorz Jaskiewicz wonderful static checker coughed up 5 errors in
geo_ops.c. None of them of any particular excitement or of earth
shattering nature. A patch is attached below that should correct these.
(The more little issue we eliminate, the more the large ones will stand
out.)
At line 3131 v
Asko Oja writes:
> Did this change hashtext() visible to users? We have been using it quite
> widely for partitioning our databases. If so then it should be marked quite
> visibly in release notes as there might be others who will be hit by this.
The hash functions are undocumented, have changed
Did this change hashtext() visible to users? We have been using it quite
widely for partitioning our databases. If so then it should be marked quite
visibly in release notes as there might be others who will be hit by this.
regards
Asko
On Mon, Feb 9, 2009 at 11:22 PM, Tom Lane wrote:
> Kenneth
But the real bottom line is: if autovacuum is working properly, it
should clean up the index before the list ever gets to the point where
it'd be sane to turn off indexscans. So I don't see why we need to hack
the planner for this at all. If any hacking is needed, it should be
in the direction o
Kenneth Marshall writes:
> I have updated the patch posted by Jeff Davis on January 9th
> to include the micro-patch above as well as updated the polymorphism
> regressions tests. This applies cleanly to the latest CVS pull.
Applied --- thanks for being persistent about resolving the doubts on th
Jeff Davis writes:
> On Wed, 2009-02-04 at 14:40 -0500, Robert Haas wrote:
>> Well, there's nothing to force that plan to be invalidated when the
>> state of the pending list changes, is there?
> Would it be unreasonable to invalidate cached plans during the pending
> list cleanup?
If the pendin
On Wed, Feb 4, 2009 at 4:23 PM, Jeff Davis wrote:
> On Wed, 2009-02-04 at 14:40 -0500, Robert Haas wrote:
>> Well, there's nothing to force that plan to be invalidated when the
>> state of the pending list changes, is there?
>>
>
> Would it be unreasonable to invalidate cached plans during the pen
On Wed, 2009-02-04 at 14:40 -0500, Robert Haas wrote:
> Well, there's nothing to force that plan to be invalidated when the
> state of the pending list changes, is there?
>
Would it be unreasonable to invalidate cached plans during the pending
list cleanup?
Anyway, it just strikes me as strange
On Wed, Feb 4, 2009 at 1:39 PM, Jeff Davis wrote:
> On Mon, 2009-02-02 at 20:38 -0500, Tom Lane wrote:
>> Also, I really think it's a pretty bad idea to make index cost
>> estimation depend on the current state of the index's pending list
>> --- that state seems far too transient to base plan choi
On Mon, 2009-02-02 at 20:38 -0500, Tom Lane wrote:
> Also, I really think it's a pretty bad idea to make index cost
> estimation depend on the current state of the index's pending list
> --- that state seems far too transient to base plan choices on.
I'm confused by this. Don't we want to base the
I looked at this a little bit --- it needs proofreading ("VACUUME"?).
Sorry, VACUUME fixed
Do we really need an additional column in pgstat table entries in
order to store something that looks like it can be derived from the
other columns? The stats tables are way too big already.
It's not
Teodor Sigaev writes:
> I'm very sorry, but v0.24 has a silly bug with not initialized value :(.
> New version is attached
I looked at this a little bit --- it needs proofreading ("VACUUME"?).
Do we really need an additional column in pgstat table entries in
order to store something that looks l
On Sun, Jan 25, 2009 at 10:27:03PM -0600, Kenneth Marshall wrote:
> On Sat, Jan 10, 2009 at 01:36:25PM -0500, Tom Lane wrote:
> > Jeff Davis writes:
> > > I ran 5 times on both old and new code, eliminating the top and bottom
> > > and taking the average of the remaining 3, and I got a 6.9% perfor
On Sat, Jan 10, 2009 at 01:36:25PM -0500, Tom Lane wrote:
> Jeff Davis writes:
> > I ran 5 times on both old and new code, eliminating the top and bottom
> > and taking the average of the remaining 3, and I got a 6.9% performance
> > improvement with the new code.
>
> The question that has been c
I'm very sorry, but v0.24 has a silly bug with not initialized value :(.
New version is attached
--
Teodor Sigaev E-mail: teo...@sigaev.ru
WWW: http://www.sigaev.ru/
fast_insert_gin-0.25.gz
Description: Unix ta
BTW, gincostestimate could use that information for cost estimation, but is
index opening and metapge reading in amcostestimate acceptable?
That sounds reasonable to me. I think that's what the index-specific
cost estimators are for.
Done.
Do you expect a performance impact?
I'm afraid fo
On Wed, 2009-01-21 at 15:06 +0300, Teodor Sigaev wrote:
> Done. Now GIN counts number of pending tuples and pages and stores they on
> metapage. Index cleanup could start during normal insertion in two cases:
> - number of pending tuples is too high to keep guaranteed non-lossy tidbitmap
> - pendi
- after limit is reached, force cleanup of pending list by calling
gininsertcleanup. Not very good, because users sometimes will see a huge
execution time of simple insert. Although users who runs a huge update should be
satisfied.
I have difficulties in a choice of way. Seems to me, the bette
On Mon, 2009-01-19 at 19:53 +0300, Teodor Sigaev wrote:
> I see only two guaranteed solution of the problem:
> - after limit is reached, force normal index inserts. One of the motivation
> of
> patch was frequent question from users: why update of whole table with GIN
> index
> is so slow? So t
I suggest you take StdRdOptions out of the GinOptions struct, and leave
fillfactor out of ginoptions. I don't think there's much point in
supporting options that don't actually do anything. If the user tries
to set fillfactor for a gin index, he will get an error. Which is a
good thing IMHO.
Alvaro Herrera writes:
> Teodor Sigaev wrote:
>> I didn't change a recognition of fillfactor value, although GIN doesn't
>> use it for now.
> I suggest you take StdRdOptions out of the GinOptions struct, and leave
> fillfactor out of ginoptions. I don't think there's much point in
> supporting
Teodor Sigaev wrote:
>> I notice you added a fillfactor reloption in ginoptions, but does it
>> really make sense? I recall removing it because the original code
>> contained a comment that says "this is here because default_reloptions
>> wants it, but it has no effect".
>
> I didn't change a reco
I notice you added a fillfactor reloption in ginoptions, but does it
really make sense? I recall removing it because the original code
contained a comment that says "this is here because default_reloptions
wants it, but it has no effect".
I didn't change a recognition of fillfactor value, altho
Teodor Sigaev wrote:
> New version. Changes:
> - synced with current CVS
I notice you added a fillfactor reloption in ginoptions, but does it
really make sense? I recall removing it because the original code
contained a comment that says "this is here because default_reloptions
wants it, but it
Changes:
Results of pernding list's scan now are placed directly in resulting
tidbitmap. This saves cycles for filtering results and reduce memory usage.
Also, it allows to not check losiness of tbm.
Is this a 100% bulletproof solution, or is it still possible for a query
to fail due to the
On Fri, 2009-01-16 at 15:39 +0300, Teodor Sigaev wrote:
> > START_CRIT_SECTION();
> > ...
> > l = PageAddItem(...);
> > if (l == InvalidOffsetNumber)
> > elog(ERROR, "failed to add item to index page in \"%s\"",
> > RelationGetRelationName(index));
> >
> > It's no use using ERROR, bec
New version. Changes:
- synced with current CVS
- added all your changes
- autovacuum will run if fast update mode is turned on and
trigger of fresh tuple is fired
- gincostestimate now tries to calculate cost of scan of pending pages.
gincostestimate set disable_cost if it believe that
On Sat, Jan 10, 2009 at 01:57:27PM -0500, Gregory Stark wrote:
> Tom Lane writes:
>
> > Jeff Davis writes:
> >> I ran 5 times on both old and new code, eliminating the top and bottom
> >> and taking the average of the remaining 3, and I got a 6.9% performance
> >> improvement with the new code.
On Sat, Jan 10, 2009 at 10:56:15AM -0800, Jeff Davis wrote:
> On Sat, 2009-01-10 at 13:36 -0500, Tom Lane wrote:
> > Jeff Davis writes:
> > > I ran 5 times on both old and new code, eliminating the top and bottom
> > > and taking the average of the remaining 3, and I got a 6.9% performance
> > > i
On Sat, 2009-01-10 at 13:57 -0500, Gregory Stark wrote:
> But I gather it's a 6% speedup in the time spent actually in the
> hash function.
That's correct. I was not able to detect any difference at all between
the old and new code using HashAggregate, which is where most of my
testing effort went
Tom Lane writes:
> Jeff Davis writes:
>> I ran 5 times on both old and new code, eliminating the top and bottom
>> and taking the average of the remaining 3, and I got a 6.9% performance
>> improvement with the new code.
>
> The question that has been carefully evaded throughout the discussion
>
On Sat, 2009-01-10 at 13:36 -0500, Tom Lane wrote:
> Jeff Davis writes:
> > I ran 5 times on both old and new code, eliminating the top and bottom
> > and taking the average of the remaining 3, and I got a 6.9% performance
> > improvement with the new code.
>
> The question that has been carefull
Jeff Davis writes:
> I ran 5 times on both old and new code, eliminating the top and bottom
> and taking the average of the remaining 3, and I got a 6.9% performance
> improvement with the new code.
The question that has been carefully evaded throughout the discussion
of this patch is whether the
On Sat, 2009-01-10 at 11:06 -0600, Kenneth Marshall wrote:
> > Separating mix() and final() should have some performance benefit,
> > right?
> >
> Yes, it does but the results can be swamped by other latencies in the
> code path. Tests such as Tom's benchmark of the underlying functions is
> neede
On Fri, Jan 09, 2009 at 02:00:39PM -0800, Jeff Davis wrote:
> On Fri, 2009-01-09 at 14:29 -0600, Kenneth Marshall wrote:
> > Jeff,
> >
> > Thanks for the review. I would not really expect any differences in hash
> > index build times other than normal noise variances. The most definitive
> > bench
On Fri, 2009-01-09 at 14:29 -0600, Kenneth Marshall wrote:
> Jeff,
>
> Thanks for the review. I would not really expect any differences in hash
> index build times other than normal noise variances. The most definitive
> benchmark that I have seen was done with my original patch submission
> in Ma
On Fri, Jan 09, 2009 at 12:04:15PM -0800, Jeff Davis wrote:
> On Mon, 2008-12-22 at 13:47 -0600, Kenneth Marshall wrote:
> > Dear PostgreSQL developers,
> >
> > I am re-sending this to keep this last change to the
> > internal hash function on the radar.
> >
>
> Hi Ken,
>
> A few comments:
>
On Mon, 2008-12-22 at 13:47 -0600, Kenneth Marshall wrote:
> Dear PostgreSQL developers,
>
> I am re-sending this to keep this last change to the
> internal hash function on the radar.
>
Hi Ken,
A few comments:
1. New patch with very minor changes attached.
2. I reverted the change you made
On Mon, 2008-12-29 at 15:06 +0900, Fujii Masao wrote:
> This seems to have not been fixed yet in the latest patch.
>
> http://archives.postgresql.org/message-id/494ff631.90...@enterprisedb.com
> recovery-infra-separated-again-1.patch
I'll add it to my issues-reported list so we can check for re
Hi,
On Tue, Nov 18, 2008 at 12:39 AM, Simon Riggs wrote:
>
> On Mon, 2008-11-17 at 16:18 +0200, Heikki Linnakangas wrote:
>> Simon Riggs wrote:
>> > @@ -3845,6 +3850,52 @@ sigusr1_handler(SIGNAL_ARGS)
>> >
>> > PG_SETMASK(&BlockSig);
>> >
>> > + if (CheckPostmasterSignal(PMSIGNAL_RE
On Mon, 2008-12-22 at 22:18 +0200, Heikki Linnakangas wrote:
> I think it's useful to review the "infra" part of the patch separately,
> so I split it out of the big patch again. I haven't looked at this in
> detail yet, but it compiles and passes regression tests.
OK, thanks, much appreciated
On Tue, Dec 23, 2008 at 5:18 AM, Heikki Linnakangas
wrote:
> Simon Riggs wrote:
>>
>> On Wed, 2008-12-17 at 23:32 -0300, Alvaro Herrera wrote:
>>>
>>> Simon Riggs escribió:
>>>
Please let me know how I can make the reviewer's job easier. Diagrams,
writeups, whatever. Thanks,
>>>
>>> A li
Kenneth Marshall wrote:
> Dear PostgreSQL developers,
>
> I am re-sending this to keep this last change to the
> internal hash function on the radar.
Please add it to the commitfest wiki page,
http://wiki.postgresql.org/wiki/CommitFest_2008-11
Thanks
--
Alvaro Herrera
Dear PostgreSQL developers,
I am re-sending this to keep this last change to the
internal hash function on the radar.
Ken
Sorry about the delay for this update to the new hash
index implementation. I was trying to get the WAL logging
in place and forgot to post the actual patch. The
On Wed, 2008-12-17 at 23:32 -0300, Alvaro Herrera wrote:
> Simon Riggs escribió:
>
> > Please let me know how I can make the reviewer's job easier. Diagrams,
> > writeups, whatever. Thanks,
>
> A link perhaps?
There is much confusion on this point for which I'm very sorry.
I originally wrote "
Simon Riggs escribió:
> Please let me know how I can make the reviewer's job easier. Diagrams,
> writeups, whatever. Thanks,
A link perhaps?
--
Alvaro Herrerahttp://www.CommandPrompt.com/
The PostgreSQL Company - Command Prompt, Inc.
--
Sent via pgsql-hackers m
On Thu, 2008-11-20 at 10:10 +, Simon Riggs wrote:
> On Thu, 2008-11-20 at 15:19 +0530, Pavan Deolasee wrote:
>
> > Do you intend to split the patch into smaller pieces ? The latest hot
> > standby patch is almost 10K+ lines. Splitting that would definitely
> > help the review process.
>
> If
On Mon, 2008-12-15 at 17:10 -0500, Bruce Momjian wrote:
> >
> > Why no backpatch to 8.3? Seems like a clear bugfix to me.
>
> I knew that was going to be asked.
8.3 is really where this is needed. 8.4 has almost no need of this.
--
Simon Riggs www.2ndQuadrant.com
PostgreSQL Train
Tom Lane wrote:
> "Heikki Linnakangas" writes:
> > Martin Zaun wrote:
> >> With these avenues to be explored, can the pg_standby patch on the
> >> CommitFest wiki be moved to the "Returned with Feedback" section?
>
> > Yes, I think we can conclude that we don't want this patch as it is.
> > Inst
1 - 100 of 3312 matches
Mail list logo