Re: [HACKERS] Back-branch releases upcoming this week

On Tue, 2011-09-20 at 01:37 -0400, Tom Lane wrote: > As has been mentioned a couple times, we're well overdue for updates > of the back branches. Seems like time to get that done, so we'll be > wrapping 8.2.x and up this Thursday for release Monday the 26th. Can we also specify a final release v

Re: [HACKERS] unite recovery.conf and postgresql.conf

On Sat, Sep 17, 2011 at 4:22 AM, Joshua Berkus wrote: >> that makes it look like one of the WAL archive transfer trigger >> files, >> which does not seem like a great analogy.  The pg_standby >> documentation >> suggests names like "foo.trigger" for failover triggers, which is a >> bit >> better a

[HACKERS] Back-branch releases upcoming this week

As has been mentioned a couple times, we're well overdue for updates of the back branches. Seems like time to get that done, so we'll be wrapping 8.2.x and up this Thursday for release Monday the 26th. regards, tom lane -- Sent via pgsql-hackers mailing list (pgsql-hacke

Re: [HACKERS] [PATCH] Use new oom_score_adj without a new compile-time constant

On Mon, Sep 19, 2011 at 3:11 PM, Dan McGee wrote: > This is one way to prevent the kernel warning message without having to > introduce a new constant. Scale the old oom_adj-style value the same way > the kernel internally does it and use that instead if oom_score_adj is > available for writing. >

[HACKERS] [PATCH] Use new oom_score_adj without a new compile-time constant

This is one way to prevent the kernel warning message without having to introduce a new constant. Scale the old oom_adj-style value the same way the kernel internally does it and use that instead if oom_score_adj is available for writing. Signed-off-by: Dan McGee --- This addresses some of the c

Re: [HACKERS] Improve lseek scalability v3

On Mon, Sep 19, 2011 at 08:31:00AM -0400, Stephen Frost wrote: > * Benjamin LaHaise (b...@kvack.org) wrote: > > For such tables, can't Postgres track the size of the file internally? I'm > > assuming it's keeping file descriptors open on the tables it manages, in > > which case when it writes to

Re: [HACKERS] File not found error on creating collation

Robert Haas writes: > On Mon, Sep 19, 2011 at 10:04 PM, Tom Lane wrote: >> We could possibly add a HINT suggesting that the locale isn't installed, >> but I don't see that we could offer any useful generic advice about how >> to install it. I'm also worried about how to phrase the hint to cover

Re: [HACKERS] Grouping Sets

Hello 2011/9/20 David Rinaldi : > Paul, > > I was able to apply the patch to 9.0.4 and so far looks good.  My Oracle > results match. Nice. > > But, when trying to calculate some percentages and control some rounding, > the results are coming back as null for some reason.  I have tried casting, >

Re: [HACKERS] File not found error on creating collation

On Mon, Sep 19, 2011 at 10:04 PM, Tom Lane wrote: > Marti Raudsepp writes: >> On Tue, Sep 20, 2011 at 03:24, Thom Brown wrote: >>> ERROR:  could not create locale "sr_SB.utf8": No such file or directory >>> It's correct in that it shouldn't be able to create the locale since >>> it's not install

Re: [HACKERS] Is there really no interest in SQL Standard?

FYI, one of the main goals of the Muldis D language is to be an "open source SQL standard". It is intended to satisfy both relational and NoSQL folks, and predates UnQL significantly. Muldis D has always been published openly and is comprehensive enough to cover anything that SQL does, and an

Re: [HACKERS] Inlining comparators as a performance optimisation

Peter Geoghegan writes: > Once the cache has been warmed, explain analyze very consistently > reports a runtime of 123ms for this query on master/HEAD, which varies > +/- 1 ms, with a few outliers of maybe +/- 2ms. However, when I apply > this patch, that goes down to 107ms +/- 1ms at -O0. I think

Re: [HACKERS] File not found error on creating collation

Marti Raudsepp writes: > On Tue, Sep 20, 2011 at 03:24, Thom Brown wrote: >> ERROR:  could not create locale "sr_SB.utf8": No such file or directory >> It's correct in that it shouldn't be able to create the locale since >> it's not installed, but what file can't it find?  What is the user >> s

[HACKERS] Inlining comparators as a performance optimisation

Recent discussions on the threads "Double sorting split patch" and "CUDA sorting" raised the possibility that there could be significant performance optimisation "low-hanging fruit" picked by having the executor treat integers and floats as a special case during sorting, avoiding going to the troub

Re: [HACKERS] Grouping Sets

Paul, I was able to apply the patch to 9.0.4 and so far looks good. My Oracle results match. Nice. But, when trying to calculate some percentages and control some rounding, the results are coming back as null for some reason. I have tried casting, to_char, etc to try to get them to show up..no

Re: [HACKERS] File not found error on creating collation

On Tue, Sep 20, 2011 at 03:24, Thom Brown wrote: > ERROR:  could not create locale "sr_SB.utf8": No such file or directory > > It's correct in that it shouldn't be able to create the locale since > it's not installed, but what file can't it find?  What is the user > supposed to do with this messag

Re: [HACKERS] Is there really no interest in SQL Standard?

On Monday, September 19, 2011 9:20 AM, "David Fetter" wrote: > On Mon, Sep 19, 2011 at 10:58:49AM -0400, Joe Abbate wrote: > > On 09/19/2011 09:50 AM, Josh Berkus wrote: > > > FWIW, the fact that the drafts *are* confidential is symptomatic > > > of everything which is wrong with the ISO. > > > >

[HACKERS] File not found error on creating collation

Hi, I don't find the following error message very helpful: =# create collation "sr_SP" (LOCALE ='sr_SB.utf8'); ERROR: could not create locale "sr_SB.utf8": No such file or directory It's correct in that it shouldn't be able to create the locale since it's not installed, but what file can't it

Re: [HACKERS] Is there really no interest in SQL Standard?

Folks, Can we move the discussion about hypothetical new standards groups over to -advocacy? This is getting a bit off-topic for -hackers. -- Josh Berkus PostgreSQL Experts Inc. http://pgexperts.com -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your

Re: [HACKERS] Is there really no interest in SQL Standard?

Hi Greg, On 09/19/2011 04:44 PM, Greg Smith wrote: > Not spending as much time sitting in meetings and fighting with other > vendors is one of the competitive advantages PostgreSQL development has > vs. the "big guys". There needs to be a pretty serious problem with > your process before adding b

Re: [HACKERS] Is there really no interest in SQL Standard?

2011/9/19 Greg Smith : > On 09/19/2011 10:58 AM, Joe Abbate wrote: >> >> Maybe it's time for an open source SQL standard, one not controlled by >> the "big guys" and their IP claims. >> > > Not spending as much time sitting in meetings and fighting with other > vendors is one of the competitive adv

Re: [HACKERS] Is there really no interest in SQL Standard?

On 09/19/2011 10:58 AM, Joe Abbate wrote: Maybe it's time for an open source SQL standard, one not controlled by the "big guys" and their IP claims. Not spending as much time sitting in meetings and fighting with other vendors is one of the competitive advantages PostgreSQL development has

Re: [HACKERS] Grouping Sets

On Sun, Sep 18, 2011 at 02:08:01PM -0500, David Rinaldi wrote: > I tried to apply the Grouping Sets Patch to 8.4, but received several Hunks > failed messages, does anyone know if the failing hunks can be applied > manually? Or what version they were applied to specifically? Your best bet is prob

Re: [HACKERS] CUDA Sorting

2011/9/19 Greg Smith : > On 09/19/2011 10:53 AM, Thom Brown wrote: >> >> But couldn't that also be seen as a chicken/egg situation? > > > The chicken/egg problem here is a bit deeper than just "no one offers GPUs > because no one wants them" on server systems.  One of the reasons there > aren't mor

Re: [HACKERS] CUDA Sorting

On Sep 19, 2011, at 5:16 PM, Tom Lane wrote: > Greg Stark writes: >> That said, to help in the case I described you would have to implement >> the tapesort algorithm on the GPU as well. > > I think the real problem would be that we are seldom sorting just the > key values. If you have to push

Re: [HACKERS] Review for EXPLAIN and nfiltered

On Mon, Sep 19, 2011 at 3:10 PM, Marc Cousin wrote: > 2011/9/19 Robert Haas : >> On Mon, Sep 19, 2011 at 12:51 PM, Marc Cousin wrote: >>> Here is my review for EXPLAIN and nfiltered >>> (http://archives.postgresql.org/message-id/4e6e9e83.7070...@2ndquadrant.com) >> >> Please add this review to th

Re: [HACKERS] Review for EXPLAIN and nfiltered

2011/9/19 Robert Haas : > On Mon, Sep 19, 2011 at 12:51 PM, Marc Cousin wrote: >> Here is my review for EXPLAIN and nfiltered >> (http://archives.postgresql.org/message-id/4e6e9e83.7070...@2ndquadrant.com) > > Please add this review to the CommitFest app here: > > https://commitfest.postgresql.org

Re: [HACKERS] CUDA Sorting

On 09/19/2011 10:53 AM, Thom Brown wrote: But couldn't that also be seen as a chicken/egg situation? The chicken/egg problem here is a bit deeper than just "no one offers GPUs because no one wants them" on server systems. One of the reasons there aren't more GPUs in typical database server

Re: [HACKERS] Is there really no interest in SQL Standard?

Christopher Browne writes: > The nearest sort of thing that *could* conceivably be sensible would > be to participate in UnQL > . That's early enough in > its process that it's likely somewhat guidable, and, with the > popularity of NoSQL, being at the "

Re: [HACKERS] PATCH: regular logging of checkpoint progress

Tom Lane writes: > On machines where gettimeofday is slow (and last I heard there were > still lots of them), any such thing would be a disaster > performance-wise. I'm still afraid to add more gettimeofday's into the > query parse/plan/execute code path, even though it would greatly ease > the p

Re: [HACKERS] CUDA Sorting

* Thom Brown (t...@linux.com) wrote: > But nVidia does produce a non-graphics-oriented GPGPU line called > Tesla dedicated to such processing. Just as a side-note, I've got a couple Tesla's that aren't doing terribly much at the moment and they're in a Linux 'server'-type box from Penguin computin

Re: [HACKERS] Review for EXPLAIN and nfiltered

On Mon, Sep 19, 2011 at 12:51 PM, Marc Cousin wrote: > Here is my review for EXPLAIN and nfiltered > (http://archives.postgresql.org/message-id/4e6e9e83.7070...@2ndquadrant.com) Please add this review to the CommitFest app here: https://commitfest.postgresql.org/action/patch_view?id=638 ...and

Re: [HACKERS] Is there really no interest in SQL Standard?

On 09/19/2011 12:40 PM, Christopher Browne wrote: > On Mon, Sep 19, 2011 at 12:20 PM, David Fetter wrote: > Actually, I think it *is* a bad idea, as it would require construction > from whole cloth of kinds of mostly political infrastructure that we > don't have, as a community and aren't necessar

[HACKERS] Review for EXPLAIN and nfiltered

Here is my review for EXPLAIN and nfiltered (http://archives.postgresql.org/message-id/4e6e9e83.7070...@2ndquadrant.com) - Is the patch in context diff format? It's in git diff format - Does it apply cleanly to the current git master? Yes - Does it include reasonable tests, necessary doc patches

Re: [HACKERS] Range Types - typo + NULL string constructor

On Mon, 2011-09-19 at 11:00 -0500, Kevin Grittner wrote: > On a practical level, our shop is already effectively doing this. > We have several tables where part of the primary key is "effective > date" and there is a null capable "expiration date" -- with a NULL > meaning that no expiration date h

Re: [HACKERS] Is there really no interest in SQL Standard?

On Mon, Sep 19, 2011 at 12:20 PM, David Fetter wrote: > On Mon, Sep 19, 2011 at 10:58:49AM -0400, Joe Abbate wrote: >> On 09/19/2011 09:50 AM, Josh Berkus wrote: >> > FWIW, the fact that the drafts *are* confidential is symptomatic >> > of everything which is wrong with the ISO. >> >> Maybe it's t

Re: [HACKERS] Is there really no interest in SQL Standard?

On 09/19/2011 12:20 PM, David Fetter wrote: On Mon, Sep 19, 2011 at 10:58:49AM -0400, Joe Abbate wrote: On 09/19/2011 09:50 AM, Josh Berkus wrote: FWIW, the fact that the drafts *are* confidential is symptomatic of everything which is wrong with the ISO. Maybe it's time for an open source SQ

Re: [HACKERS] Range Types - typo + NULL string constructor

On Sep19, 2011, at 17:46 , Jeff Davis wrote: > On Mon, 2011-09-19 at 17:23 +0200, Florian Pflug wrote: >> The one reason I can see in favour of supporting N-U-L-L there is >> compatibility with arrays. > > But arrays actually do store and produce NULLs; ranges don't. Hm, yeah, granted. But OTOH,

Re: [HACKERS] Range Types - typo + NULL string constructor

On Mon, Sep 19, 2011 at 11:23 AM, Florian Pflug wrote: > On Sep19, 2011, at 15:33 , Robert Haas wrote: >> On Mon, Sep 19, 2011 at 1:51 AM, Jeff Davis wrote: select '[ 2 , NULL )'::int4range; ERROR:  NULL range boundaries are not supported LINE 1: select '[ 2 , NULL )'::int4range; >

Re: [HACKERS] CUDA Sorting

On Mon, Sep 19, 2011 at 10:36 AM, Greg Smith wrote: > Intel's next generation Ivy Bridge chipset, expected for the spring of 2012, > is going to add support for OpenCL to the built-in motherboard GPU.  We may > eventually see that trickle into the server hardware side of things too. Note that Ama

Re: [HACKERS] CUDA Sorting

On Mon, Sep 19, 2011 at 7:11 AM, Vitor Reus wrote: > Hello everyone, > > I'm implementing a CUDA based sorting on PostgreSQL, and I believe it > can improve the ORDER BY statement performance in 4 to 10 times. I > already have a generic CUDA sort that performs around 10 times faster > than std qso

Re: [HACKERS] Is there really no interest in SQL Standard?

On Mon, Sep 19, 2011 at 10:58:49AM -0400, Joe Abbate wrote: > On 09/19/2011 09:50 AM, Josh Berkus wrote: > > FWIW, the fact that the drafts *are* confidential is symptomatic > > of everything which is wrong with the ISO. > > Maybe it's time for an open source SQL standard, one not controlled > by

Re: [HACKERS] Generating a query that never returns

On Sep19, 2011, at 17:59 , David Fetter wrote: > On Mon, Sep 19, 2011 at 05:12:15PM +0200, Florian Pflug wrote: >> My first try, BTW, was >> >> WITH RECURSIVE infinite(value) AS (SELECT 1 UNION ALL SELECT 1) >> SELECT * FROM infinite >> >> but that returns only two rows. I'd have expected it t

Re: [HACKERS] Range Types - typo + NULL string constructor

Robert Haas wrote: > Jeff Davis wrote: >>> select '[ 2 , NULL )'::int4range; >>> ERROR: NULL range boundaries are not supported >>> LINE 1: select '[ 2 , NULL )'::int4range; >> >> I think this might require more opinions. There is a trade-off >> here between convenience and confusion: accepting

Re: [HACKERS] Generating a query that never returns

On Mon, Sep 19, 2011 at 05:12:15PM +0200, Florian Pflug wrote: > On Sep19, 2011, at 16:48 , Dave Cramer wrote: > > I have a need to test timeouts in JDBC, is there a query that is > > guaranteed not to return ? > > WITH RECURSIVE infinite(value) AS (SELECT 1 UNION ALL SELECT * FROM infinite) > SEL

Re: [HACKERS] A little pg_dump patch

Ok, but with this hack I need 2 databases, one with comments and another without comments. I prefer to have only one db with comments and choice to have a dump with comments or without comments. regards, Enrico 2011/9/19 Greg Sabino Mullane : > > -BEGIN PGP SIGNED MESSAGE- > Hash: RIPEMD1

Re: [HACKERS] CUDA Sorting

2011/9/19 Thom Brown > Is your aim to have this committed into core PostgreSQL, or just for > your own version?  If it's the former, I don't anticipate any > enthusiasm from the hacker community. This is a research thesis and I'm not confident to commit it on the core just by myself. I will, howe

Re: [HACKERS] Range Types - typo + NULL string constructor

On Mon, 2011-09-19 at 17:23 +0200, Florian Pflug wrote: > The one reason I can see in favour of supporting N-U-L-L there is > compatibility with arrays. But arrays actually do store and produce NULLs; ranges don't. > I've recently had the questionable pleasure > of writing PHP functions to pars

Re: [HACKERS] A little pg_dump patch

-BEGIN PGP SIGNED MESSAGE- Hash: RIPEMD160 >> I wrote this little patch, becuse my customer doesn't want to have >> comments on the production db. It's not my choice > > Then use pg_restore --use-list to filter them out, and you won't need a Or just strip them out after the fact with

Re: [HACKERS] A little pg_dump patch

> Patching pg_dump like this seems like the wrong way to go. Ok ;) Thank you very much Enrico -- That's one small step for man; one giant leap for mankind -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/m

Re: [HACKERS] A little pg_dump patch

On 09/19/2011 11:23 AM, Enrico Pirozzi wrote: What's the use case for not dumping comments? At first glance it seems a very odd thing to do. I wrote this little patch, becuse my customer doesn't want to have comments on the production db. It's not my choice Then use pg_restore --use-lis

Re: [HACKERS] Range Types - typo + NULL string constructor

On Sep19, 2011, at 15:33 , Robert Haas wrote: > On Mon, Sep 19, 2011 at 1:51 AM, Jeff Davis wrote: >>> select '[ 2 , NULL )'::int4range; >>> ERROR: NULL range boundaries are not supported >>> LINE 1: select '[ 2 , NULL )'::int4range; >> >> I think this might require more opinions. There is a tra

Re: [HACKERS] A little pg_dump patch

> What's the use case for not dumping comments? At first glance it seems a > very odd thing to do. > > cheers > > andrew I wrote this little patch, becuse my customer doesn't want to have comments on the production db. It's not my choice Regards, Enrico -- That's one small step for man; on

Re: [HACKERS] CUDA Sorting

Greg Stark writes: > That said, to help in the case I described you would have to implement > the tapesort algorithm on the GPU as well. I think the real problem would be that we are seldom sorting just the key values. If you have to push the tuples through the GPU too, your savings are going to

Re: [HACKERS] PATCH: regular logging of checkpoint progress

Greg Smith writes: > One thing I am trying to avoid here is needing to check the system clock > after every buffer write. On machines where gettimeofday is slow (and last I heard there were still lots of them), any such thing would be a disaster performance-wise. I'm still afraid to add more ge

Re: [HACKERS] Is there really no interest in SQL Standard?

On 19.09.2011 15:50, Josh Berkus wrote: +1 for a closed mailing list. It's a bit annoying to have to do such a thing, but it's not like we haven't got other closed lists for appropriate purposes. I guess the real question is, exactly what will be the requirements for joining? Well, one require

Re: [HACKERS] CUDA Sorting

On 19 September 2011 16:10, Thom Brown wrote: > On 19 September 2011 15:54, Greg Stark wrote: >> On Mon, Sep 19, 2011 at 3:36 PM, Greg Smith wrote: >>> The main problem here is that the sort of hardware commonly used for >>> production database servers doesn't have any serious enough GPU to supp

Re: [HACKERS] Generating a query that never returns

On Sep19, 2011, at 16:48 , Dave Cramer wrote: > I have a need to test timeouts in JDBC, is there a query that is > guaranteed not to return ? WITH RECURSIVE infinite(value) AS (SELECT 1 UNION ALL SELECT * FROM infinite) SELECT * FROM infinite If you declare a cursor for this statement, it will re

Re: [HACKERS] CUDA Sorting

On 19 September 2011 15:54, Greg Stark wrote: > On Mon, Sep 19, 2011 at 3:36 PM, Greg Smith wrote: >> The main problem here is that the sort of hardware commonly used for >> production database servers doesn't have any serious enough GPU to support >> CUDA/OpenCL available > > Of course that coul

Re: [HACKERS] Generating a query that never returns

-BEGIN PGP SIGNED MESSAGE- Hash: RIPEMD160 > I have a need to test timeouts in JDBC, is there a query that is > guaranteed not to return ? Not *never*, but close enough: select pg_sleep(); Or if you want to be strict: CREATE FUNCTION no

Re: [HACKERS] A little pg_dump patch

On 09/19/2011 10:34 AM, Enrico Pirozzi wrote: Hi, I'm Enrico, I wrote a little pg_dump patch, I have introduced a new option to have a database dump without comments, no 'COMMENT ON' are written on the dump if my new option is selected. If this little piece of code can interest somebody, I'll

Re: [HACKERS] Generating a query that never returns

Dave Cramer writes: > I have a need to test timeouts in JDBC, is there a query that is > guaranteed not to return ? You could just do an unconstrained join between several large tables. Or "select pg_sleep(largevalue)", depending on whether you'd like the backend to be spitting data at you or not

Re: [HACKERS] Is there really no interest in SQL Standard?

On 09/19/2011 09:50 AM, Josh Berkus wrote: > FWIW, the fact that the drafts *are* confidential is symptomatic of > everything which is wrong with the ISO. Maybe it's time for an open source SQL standard, one not controlled by the "big guys" and their IP claims. Joe -- Sent via pgsql-hackers mai

Re: [HACKERS] CUDA Sorting

On Mon, Sep 19, 2011 at 3:36 PM, Greg Smith wrote: > The main problem here is that the sort of hardware commonly used for > production database servers doesn't have any serious enough GPU to support > CUDA/OpenCL available Of course that could change if adding a GPU would help Postgres... I would

Re: [HACKERS] PATCH: regular logging of checkpoint progress

On 09/05/2011 07:52 PM, Tomas Vondra wrote: If your logging criteria for the write phase was "display a message any time more than 30 seconds have passed since last seeing one", that would give you only a few lines of output in a boring, normal checkpoint--certainly less than the 9 in-progress sa

Re: [HACKERS] CUDA Sorting

On 19 September 2011 15:36, Greg Smith wrote: > On 09/19/2011 10:12 AM, Greg Stark wrote: >> >> With the GPU I'm curious to see how well >> it handles multiple processes contending for resources, it might be a >> flashy feature that gets lots of attention but might not really be >> very useful in

[HACKERS] Generating a query that never returns

I have a need to test timeouts in JDBC, is there a query that is guaranteed not to return ? Dave Cramer dave.cramer(at)credativ(dot)ca http://www.credativ.ca -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mai

Re: [HACKERS] CUDA Sorting

On 09/19/2011 10:12 AM, Greg Stark wrote: With the GPU I'm curious to see how well it handles multiple processes contending for resources, it might be a flashy feature that gets lots of attention but might not really be very useful in practice. But it would be very interesting to see. The m

[HACKERS] A little pg_dump patch

Hi, I'm Enrico, I wrote a little pg_dump patch, I have introduced a new option to have a database dump without comments, no 'COMMENT ON' are written on the dump if my new option is selected. If this little piece of code can interest somebody, I'll be happy to share it with the community, Regards,

Re: [HACKERS] /proc/self/oom_adj is deprecated in newer Linux kernels

Peter Eisentraut writes: > On sön, 2011-09-18 at 12:21 -0400, Tom Lane wrote: >> But having said that, it wouldn't be very hard to arrange things so that >> if you did have both symbols defined, the code would only attempt to >> write oom_adj if it had failed to write oom_score_adj; which is abou

Re: [HACKERS] CUDA Sorting

On Mon, Sep 19, 2011 at 1:11 PM, Vitor Reus wrote: > Since I'm new to pgsql development, I replaced the code of pgsql > qsort_arg to get used with the way postgres does the sort. The problem > is that I can't use the qsort_arg_comparator comparator function on > GPU, I need to implement my own. I

Re: [HACKERS] Is there really no interest in SQL Standard?

> +1 for a closed mailing list. It's a bit annoying to have to do such > a thing, but it's not like we haven't got other closed lists for > appropriate purposes. I guess the real question is, exactly what will > be the requirements for joining? Well, one requirement would be agreeing not to sha

Re: [HACKERS] CUDA Sorting

On 19 September 2011 14:32, Vitor Reus wrote: > 2011/9/19 Thom Brown : >> On 19 September 2011 13:11, Vitor Reus wrote: >>> Hello everyone, >>> >>> I'm implementing a CUDA based sorting on PostgreSQL, and I believe it >>> can improve the ORDER BY statement performance in 4 to 10 times. I >>> alre

Re: [HACKERS] Range Types - typo + NULL string constructor

On Mon, Sep 19, 2011 at 1:51 AM, Jeff Davis wrote: >> select '[ 2 , NULL )'::int4range; >> ERROR:  NULL range boundaries are not supported >> LINE 1: select '[ 2 , NULL )'::int4range; > > I think this might require more opinions. There is a trade-off here > between convenience and confusion: accep

Re: [HACKERS] Improve lseek scalability v3

On Mon, Sep 19, 2011 at 8:31 AM, Stephen Frost wrote: > * Benjamin LaHaise (b...@kvack.org) wrote: >> For such tables, can't Postgres track the size of the file internally?  I'm >> assuming it's keeping file descriptors open on the tables it manages, in >> which case when it writes to a file to ex

Re: [HACKERS] Improve lseek scalability v3

* Benjamin LaHaise (b...@kvack.org) wrote: > For such tables, can't Postgres track the size of the file internally? I'm > assuming it's keeping file descriptors open on the tables it manages, in > which case when it writes to a file to extend it, the internally stored size > could be updated.

Re: [HACKERS] CUDA Sorting

On 19 September 2011 13:11, Vitor Reus wrote: > Hello everyone, > > I'm implementing a CUDA based sorting on PostgreSQL, and I believe it > can improve the ORDER BY statement performance in 4 to 10 times. I > already have a generic CUDA sort that performs around 10 times faster > than std qsort. I

[HACKERS] CUDA Sorting

Hello everyone, I'm implementing a CUDA based sorting on PostgreSQL, and I believe it can improve the ORDER BY statement performance in 4 to 10 times. I already have a generic CUDA sort that performs around 10 times faster than std qsort. I also managed to load CUDA into pgsql. Since I'm new to p

Re: [HACKERS] Adding CORRESPONDING to Set Operations

Is it feasible to implement the CORRESPONDING [BY (expr_list)] statement in set operations by the following changes: i) In analyze.c:transformSetOperationStmt after parsing left and right queries as subnodes to a set operation tree, a) CORRESPONDING: Find matching column targets from both stat

Re: [HACKERS] Cross-compile of 3rd-party extensions fails

2011-09-19 10:27 keltezéssel, Peter Eisentraut írta: > On mån, 2011-09-19 at 10:16 +0200, Boszormenyi Zoltan wrote: >> [zozo@localhost postgis-1.5.3]$ mingw64-make >> >> make -C liblwgeom >> make[1]: Entering directory >> `/home/zozo/Schönig-számlák/w64/nsis/9.0/postgis-1.5.3/liblwgeom' >> make[1]

Re: [HACKERS] Cross-compile of 3rd-party extensions fails

On Mon, Sep 19, 2011 at 11:27 AM, Peter Eisentraut wrote: > On mån, 2011-09-19 at 10:16 +0200, Boszormenyi Zoltan wrote: >> [zozo@localhost postgis-1.5.3]$ mingw64-make >> >> make -C liblwgeom >> make[1]: Entering directory >> `/home/zozo/Schönig-számlák/w64/nsis/9.0/postgis-1.5.3/liblwgeom' >> m

Re: [HACKERS] Cross-compile of 3rd-party extensions fails

On mån, 2011-09-19 at 10:16 +0200, Boszormenyi Zoltan wrote: > [zozo@localhost postgis-1.5.3]$ mingw64-make > > make -C liblwgeom > make[1]: Entering directory > `/home/zozo/Schönig-számlák/w64/nsis/9.0/postgis-1.5.3/liblwgeom' > make[1]: Nothing to be done for `all'. > make[1]: Leaving directory

Re: [HACKERS] /proc/self/oom_adj is deprecated in newer Linux kernels

On sön, 2011-09-18 at 12:21 -0400, Tom Lane wrote: > Peter Eisentraut writes: > > On fre, 2011-09-16 at 10:57 -0400, Tom Lane wrote: > >> So it looks like it behooves us to cater for oom_score_adj in the > >> future. The simplest, least risky change that I can think of is to > >> copy-and-paste t

[HACKERS] Cross-compile of 3rd-party extensions fails

Hi, I am trying to cross-compile PostgreSQL 9.0.4 and a few 3rd-party external modules using Mingw32-w64 on Fedora 15 for 64-bit Windows. 64-bit Wine can be used to run the 64-bit pg_config.exe under Linux, so the USE_PGXS=1 machinery works. However, mingw64-make fails with the following error: [

Re: [HACKERS] Range Types - typo + NULL string constructor

hello sorry for late assign to discussion. I don't think so using NULL instead INF is a good idea. Regards Pavel Stehule 2011/9/19 Jeff Davis : > On Sun, 2011-09-18 at 18:08 +0200, Erik Rijkers wrote: >> Below are 2 changes.  The first change is an elog saying 'lower' instead of >> 'upper'. >