Re: [HACKERS] Patches that don't apply or don't compile: 2017-09-12

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

Re: [HACKERS] Patches that don't apply or don't compile: 2017-09-12

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 >

Re: [HACKERS] Patches that don't apply or don't compile: 2017-09-12

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

Re: [HACKERS] Patches that don't apply or don't compile: 2017-09-12

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 >

Re: [HACKERS] Patches that don't apply or don't compile: 2017-09-12

> 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

Re: [HACKERS] Patches that don't apply or don't compile: 2017-09-12

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

Re: [HACKERS] Patches that don't apply or don't compile: 2017-09-12

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

Re: [HACKERS] Patches that don't apply or don't compile: 2017-09-12

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

Re: [HACKERS] Patches that don't apply or don't compile: 2017-09-12

At Wed, 13 Sep 2017 08:13:08 +0900, Michael Paquier wrote in

Re: [HACKERS] Patches that don't apply or don't compile: 2017-09-12

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

Re: [HACKERS] Patches that don't apply or don't compile: 2017-09-12

> 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

Re: [HACKERS] Patches that don't apply or don't compile: 2017-09-12

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

Re: [HACKERS] Patches that don't apply or don't compile: 2017-09-12

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

Re: [HACKERS] Patches that don't apply or don't compile: 2017-09-12

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

Re: [HACKERS] Patches that don't apply or don't compile: 2017-09-12

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

[HACKERS] Patches that don't apply or don't compile: 2017-09-12

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

Re: [HACKERS] Patches I'm thinking of pushing shortly

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 >

Re: [HACKERS] Patches I'm thinking of pushing shortly

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

Re: [HACKERS] Patches I'm thinking of pushing shortly

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

Re: [HACKERS] Patches I'm thinking of pushing shortly

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

Re: [HACKERS] Patches I'm thinking of pushing shortly

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

Re: [HACKERS] Patches I'm thinking of pushing shortly

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

Re: [HACKERS] Patches I'm thinking of pushing shortly

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

Re: [HACKERS] Patches I'm thinking of pushing shortly

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

[HACKERS] Patches I'm thinking of pushing shortly

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

Re: [HACKERS] Patches for TODO item: Avoid truncating empty OCDR temp tables on COMMIT

On Mon, Jan 28, 2013 at 8:39 AM, Heikki Linnakangas hlinnakan...@vmware.com wrote: On 15.01.2013 21:03, Tom Lane wrote: Robert Haasrobertmh...@gmail.com writes: On the third hand, the fact that a table is OCDR is recorded in backend-local storage somewhere, and that storage (unlike the

Re: [HACKERS] Patches for TODO item: Avoid truncating empty OCDR temp tables on COMMIT

Gurjeet Singh singh.gurj...@gmail.com writes: On Mon, Jan 14, 2013 at 10:33 PM, Tom Lane t...@sss.pgh.pa.us 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

Re: [HACKERS] Patches for TODO item: Avoid truncating empty OCDR temp tables on COMMIT

On Tue, Jan 15, 2013 at 10:57 AM, Tom Lane t...@sss.pgh.pa.us wrote: Gurjeet Singh singh.gurj...@gmail.com writes: On Mon, Jan 14, 2013 at 10:33 PM, Tom Lane t...@sss.pgh.pa.us wrote: I think this is unacceptable on its face. It essentially supposes that relcache entries are reliable storage.

Re: [HACKERS] Patches for TODO item: Avoid truncating empty OCDR temp tables on COMMIT

Robert Haas robertmh...@gmail.com 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

Re: [HACKERS] Patches for TODO item: Avoid truncating empty OCDR temp tables on COMMIT

Gurjeet Singh singh.gurj...@gmail.com 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

Re: [HACKERS] Patches for TODO item: Avoid truncating empty OCDR temp tables on COMMIT

On Mon, Jan 14, 2013 at 10:33 PM, Tom Lane t...@sss.pgh.pa.us wrote: Gurjeet Singh singh.gurj...@gmail.com 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.

Re: [HACKERS] patches that could use additional reviewers

[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:

Re: [HACKERS] patches that could use additional reviewers

On Wed, Feb 9, 2011 at 1:45 PM, Robert Haas robertmh...@gmail.com 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

[HACKERS] patches that could use additional reviewers

On Wed, Feb 9, 2011 at 1:35 PM, Stephen Frost sfr...@snowman.net wrote: * Robert Haas (robertmh...@gmail.com) wrote: On Wed, Feb 9, 2011 at 1:09 PM, David E. Wheeler da...@kineticode.com wrote: Frankly, I think you should surrender some of those 14 and cajole some other folks to take on

Re: [HACKERS] patches that could use additional reviewers

* 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 move

Re: [HACKERS] patches that could use additional reviewers

--On 9. Februar 2011 13:45:11 -0500 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: I'd happily jump in and look into one of those, but before

Re: [HACKERS] [PATCHES] updated hash functions for postgresql v1

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/Proxy

Re: [HACKERS] [PATCHES] updated hash functions for postgresql v1

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. I

Re: [HACKERS] [PATCHES] updated hash functions for postgresql v1

Hannu Krosing ha...@2ndquadrant.com 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

Re: [HACKERS] [PATCHES] updated hash functions for postgresql v1

On Thu, 2009-10-29 at 09:32 -0400, Tom Lane wrote: Hannu Krosing ha...@2ndquadrant.com 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

Re: [HACKERS] [PATCHES] updated hash functions for postgresql v1

On Thu, 2009-10-29 at 09:32 -0400, Tom Lane wrote: Hannu Krosing ha...@2ndquadrant.com 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

Re: [HACKERS] [PATCHES] updated hash functions for postgresql v1

On Wed, 2009-02-11 at 11:22 -0500, Tom Lane wrote: Asko Oja asc...@gmail.com 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

Re: [HACKERS] [PATCHES] updated hash functions for postgresql v1

Hannu Krosing ha...@2ndquadrant.com 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

Re: [HACKERS] [PATCHES] updated hash functions for postgresql v1

On Wed, Oct 28, 2009 at 03:31:17PM -0400, Tom Lane wrote: Hannu Krosing ha...@2ndquadrant.com 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

Re: [HACKERS] [PATCHES] updated hash functions for postgresql v1

Kenneth Marshall k...@rice.edu 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

Re: [HACKERS] [PATCHES] updated hash functions for postgresql v1

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 stop?

Re: [HACKERS] [PATCHES] updated hash functions for postgresql v1

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 we

Re: [HACKERS] [PATCHES] updated hash functions for postgresql v1

On Wed, 2009-10-28 at 15:31 -0400, Tom Lane wrote: Hannu Krosing ha...@2ndquadrant.com 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.

[HACKERS] Patches for static check on geo_ops.c

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

Re: [HACKERS] Patches for static check on geo_ops.c

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,

Re: [HACKERS] Patches for static check on geo_ops.c

Paul Matthews p...@netspace.net.au 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

Re: [HACKERS] Patches for static check on geo_ops.c

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 from

Re: [HACKERS] [PATCHES] GIN improvements

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

Re: [HACKERS] [PATCHES] updated hash functions for postgresql v1

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

Re: [HACKERS] [PATCHES] updated hash functions for postgresql v1

Asko Oja asc...@gmail.com 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,

Re: [HACKERS] [PATCHES] GIN improvements

Jeff Davis pg...@j-davis.com 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

Re: [HACKERS] [PATCHES] updated hash functions for postgresql v1

Kenneth Marshall k...@rice.edu 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

Re: [HACKERS] [PATCHES] GIN improvements

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

Re: [HACKERS] [PATCHES] GIN improvements

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

Re: [HACKERS] [PATCHES] GIN improvements

On Wed, Feb 4, 2009 at 1:39 PM, Jeff Davis pg...@j-davis.com 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

Re: [HACKERS] [PATCHES] GIN improvements

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 to

Re: [HACKERS] [PATCHES] GIN improvements

On Wed, Feb 4, 2009 at 4:23 PM, Jeff Davis pg...@j-davis.com 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

Re: [HACKERS] [PATCHES] GIN improvements

Teodor Sigaev teo...@sigaev.ru 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

Re: [HACKERS] [PATCHES] updated hash functions for postgresql v1

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 pg...@j-davis.com 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

Re: [HACKERS] [PATCHES] updated hash functions for postgresql v1

On Sat, Jan 10, 2009 at 01:36:25PM -0500, Tom Lane wrote: Jeff Davis pg...@j-davis.com 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

Re: [HACKERS] [PATCHES] GIN improvements

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

Re: [HACKERS] [PATCHES] GIN improvements

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

Re: [HACKERS] [PATCHES] GIN improvements

- 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

Re: [HACKERS] [PATCHES] GIN improvements

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 - pending

Re: [HACKERS] [PATCHES] GIN improvements

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 this

Re: [HACKERS] [PATCHES] GIN improvements

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

Re: [HACKERS] [PATCHES] GIN improvements

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

Re: [HACKERS] [PATCHES] GIN improvements

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,

Re: [HACKERS] [PATCHES] GIN improvements

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 recognition of

Re: [HACKERS] [PATCHES] GIN improvements

Alvaro Herrera alvhe...@commandprompt.com 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

Re: [HACKERS] [PATCHES] GIN improvements

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.

Re: [HACKERS] [PATCHES] GIN improvements

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, because it will turn

Re: [HACKERS] [PATCHES] GIN improvements

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

Re: [HACKERS] [PATCHES] updated hash functions for postgresql v1

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 benchmark that

Re: [HACKERS] [PATCHES] updated hash functions for postgresql v1

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 needed to

Re: [HACKERS] [PATCHES] updated hash functions for postgresql v1

Jeff Davis pg...@j-davis.com 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

Re: [HACKERS] [PATCHES] updated hash functions for postgresql v1

On Sat, 2009-01-10 at 13:36 -0500, Tom Lane wrote: Jeff Davis pg...@j-davis.com 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

Re: [HACKERS] [PATCHES] updated hash functions for postgresql v1

Tom Lane t...@sss.pgh.pa.us writes: Jeff Davis pg...@j-davis.com 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

Re: [HACKERS] [PATCHES] updated hash functions for postgresql v1

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:

Re: [HACKERS] [PATCHES] updated hash functions for postgresql v1

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 pg...@j-davis.com 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%

Re: [HACKERS] [PATCHES] updated hash functions for postgresql v1

On Sat, Jan 10, 2009 at 01:57:27PM -0500, Gregory Stark wrote: Tom Lane t...@sss.pgh.pa.us writes: Jeff Davis pg...@j-davis.com 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

Re: [HACKERS] [PATCHES] updated hash functions for postgresql v1

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 to

Re: [HACKERS] [PATCHES] updated hash functions for postgresql v1

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: 1. New patch

Re: [HACKERS] [PATCHES] updated hash functions for postgresql v1

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 March

Re: [HACKERS] [PATCHES] Infrastructure changes for recovery (v8)

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: [HACKERS] [PATCHES] Infrastructure changes for recovery (v8)

Hi, On Tue, Nov 18, 2008 at 12:39 AM, Simon Riggs si...@2ndquadrant.com 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

Re: [HACKERS] [PATCHES] Infrastructure changes for recovery (v8)

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.

Re: [HACKERS] [PATCHES] updated hash functions for postgresql v1

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

Re: [HACKERS] [PATCHES] updated hash functions for postgresql v1

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

Re: [HACKERS] [PATCHES] Infrastructure changes for recovery (v8)

On Tue, Dec 23, 2008 at 5:18 AM, Heikki Linnakangas heikki.linnakan...@enterprisedb.com 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.

Re: [HACKERS] [PATCHES] Infrastructure changes for recovery (v8)

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 it helps

Re: [HACKERS] [PATCHES] Infrastructure changes for recovery (v8)

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

Re: [HACKERS] [PATCHES] Infrastructure changes for recovery (v8)

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 infra

Re: [HACKERS][PATCHES] odd output in restore mode

Martin Zaun wrote: 4. Issue: missing break in switch, silent override of '-l' argument? This behaviour has been in there before and is not addresses by the patch: The user-selected Win32 mklink command mode is never applied due to a missing 'break' in CustomizableInitialize(): switch

Re: [HACKERS][PATCHES] odd output in restore mode

Bruce Momjian wrote: Martin Zaun wrote: 4. Issue: missing break in switch, silent override of '-l' argument? This behaviour has been in there before and is not addresses by the patch: The user-selected Win32 mklink command mode is never applied due to a missing 'break' in

  1   2   3   4   5   6   7   8   9   10   >