Re: [HACKERS] converting datum to numeric

On 25 June 2013 08:51, Pavel Stehule wrote: > Hello > > 2013/6/25 Szymon Guz : > > Hi, > > I've got a couple of questions. > > > > I was using numeric_out like this: > > > > DatumGetCString(DirectFunctionCall1(numeric_out, d)); > > > > Why do I have to use DirectFunctionCall1 instead of calling n

Re: [HACKERS] [9.4 CF 1] The Commitfest Slacker List

On Tue, Jun 25, 2013 at 3:56 PM, Tom Lane wrote: > > FWIW, a large part of the reason for the commitfest structure is that > by reviewing patches, people can educate themselves about parts of the > PG code that they don't know already, and thus become better qualified > to do more stuff later. S

Re: [HACKERS] [9.4 CF 1] The Commitfest Slacker List

On 25 June 2013 04:13, Joshua D. Drake wrote: > On 06/24/2013 10:59 AM, Andres Freund wrote: >> On 2013-06-24 10:50:42 -0700, Josh Berkus wrote: >>> This project is enormously stingy with giving credit to people. It's >>> not like it costs us money, you know. >> I am all for introducing a "Contri

[HACKERS] PostgreSQL 9.3 latest dev snapshot

Hi, Where we can find latest snapshot for 9.3 version? We have taken latest snapshot from http://ftp.postgresql.org/pub/snapshot/dev/ But it seems it is for 9.4 version... Thanks, Misa

Re: [HACKERS] Reduce maximum error in tuples estimation after vacuum.

Hello, > I have tried to reproduce the problem in different m/c's, but couldn't > reproduce it. > I have ran tests with default configuration. I think you had reproduced it. > Output on Windows: > --- > postgres=# create table t (a int, b int); (snip) > postgres=# select n_live

Re: [HACKERS] [Review] Add SPI_gettypmod() to return a field's typemod from a TupleDesc

Hi Mark, Is this the latest patch you are targeting for 9.4 CF1 ? I am going to review it. >From the comment, here is one issue you need to resolve first: *** exec_eval_datum(PLpgSQL_execstate *estat *** 4386,4396 errmsg("record \"%s\" has no fiel

Re: [HACKERS] proposal: enable new error fields in plpgsql (9.4)

Hi Pavel, I gone through the discussion over here and found that with this patch we enable the new error fields in plpgsql. Its a simple patch to expose the new error fields in plpgsql. Patch gets applied cleanly. make and make install too went smooth. make check was smooth too. Patch also includ

Re: [HACKERS] proposal: enable new error fields in plpgsql (9.4)

2013/6/25 Rushabh Lathia : > Hi Pavel, > > I gone through the discussion over here and found that with this patch we > enable the new error fields in plpgsql. Its a simple patch to expose the new > error fields in plpgsql. > > Patch gets applied cleanly. make and make install too went smooth. make

Re: [HACKERS] Add more regression tests for CREATE OPERATOR

Thanks a ton Szymon (for a reminder on this one). As a coincidental turn of events, I have had to travel half way across the world and am without my personal laptop (without a linux distro etc.) and just recovering from a jet-lag now. I'll try to install a VM on a make-shift laptop and get somet

Re: [HACKERS] proposal: enable new error fields in plpgsql (9.4)

On Tue, Jun 25, 2013 at 2:41 PM, Pavel Stehule wrote: > 2013/6/25 Rushabh Lathia : > > Hi Pavel, > > > > I gone through the discussion over here and found that with this patch we > > enable the new error fields in plpgsql. Its a simple patch to expose the > new > > error fields in plpgsql. > > > >

Re: [HACKERS] Department of Redundancy Department: makeNode(FuncCall) division

On Tue, Jun 25, 2013 at 11:11 AM, Jeevan Chalke < jeevan.cha...@enterprisedb.com> wrote: > Hi David, > > I hope this is the latest patch to review, right ? > > I am going to review it. > > I have gone through the discussion on this thread and I agree with Stephen > Frost that it don't add much imp

Re: [HACKERS] PostgreSQL 9.3 latest dev snapshot

On Tue, Jun 25, 2013 at 5:33 PM, Misa Simic wrote: > Hi, > > Where we can find latest snapshot for 9.3 version? > > We have taken latest snapshot from > http://ftp.postgresql.org/pub/snapshot/dev/ > > But it seems it is for 9.4 version... 9.3 has moved to branch REL9_3_STABLE a couple of days ago.

Re: [HACKERS] [PATCH] Fix conversion for Decimal arguments in plpython functions

On 25 June 2013 05:16, Steve Singer wrote: > > One concern I have is that this patch makes pl/python functions involving > numerics more than 3 times as slow as before. > > > create temp table b(a numeric); > insert into b select generate_series(1,1); > > create or replace function x(a numeri

Re: [HACKERS] proposal: enable new error fields in plpgsql (9.4)

2013/6/25 Rushabh Lathia : > > > > On Tue, Jun 25, 2013 at 2:41 PM, Pavel Stehule > wrote: >> >> 2013/6/25 Rushabh Lathia : >> > Hi Pavel, >> > >> > I gone through the discussion over here and found that with this patch >> > we >> > enable the new error fields in plpgsql. Its a simple patch to exp

Re: [HACKERS] [PATCH] Fix conversion for Decimal arguments in plpython functions

On 25 June 2013 05:16, Steve Singer wrote: > On 05/28/2013 04:41 PM, Szymon Guz wrote: > >> Hi, >> I've got a patch. >> >> This is for a plpython enhancement. >> >> There is an item at the TODO list http://wiki.postgresql.org/** >> wiki/Todo#Server-Side_**Languages

Re: [HACKERS] patch submission: truncate trailing nulls from heap rows to reduce the size of the null bitmap [Review]

On Monday, June 24, 2013 8:20 PM Tom Lane wrote: > Amit Kapila writes: > > I will summarize the results, and if most of us feel that they are > not good > > enough, then we can return this patch. > > Aside from the question of whether there's really any generally-useful > performance improvement

Re: [HACKERS] Naming of ORDINALITY column

On 24 June 2013 04:29, Josh Berkus wrote: > On 06/23/2013 08:00 PM, Andrew Gierth wrote: >> OK, let's try to cover all the bases here in one go. > >> 1. Stick with "?column?" as a warning flag that you're not supposed to >> be using this without aliasing it to something. > > How do I actually supp

Re: FILTER for aggregates [was Re: [HACKERS] Department of Redundancy Department: makeNode(FuncCall) division]

On 24 June 2013 03:50, Tom Lane wrote: > David Fetter writes: >> On Sun, Jun 23, 2013 at 07:44:26AM -0700, Kevin Grittner wrote: >>> I think it is OK if that gets a syntax error. If that's the "worst >>> case" I like this approach. > >> I think reducing the usefulness of error messages is someth

Re: [HACKERS] Index on regexes

On 13.06.2013 23:19, Alexander Korotkov wrote: Hackers, Attached patch contains opclass which demonstrates advantages of GIN additional information storing itself without other GIN improvements. It implements inversed task of regex indexing. It works so: you create index on regexes and search fo

Re: [HACKERS] [PATCH] Fix conversion for Decimal arguments in plpython functions

Concerning the efficiency problem, it should be noted that the latest 3.3 release of cpython introduces an "accelerator" for decimal data types, as a C-module. This module was previously available from the Python package index at: https://pypi.python.org/pypi/cdecimal/2.2 It may be overkill to tr

Re: [HACKERS] [PATCH] Fix conversion for Decimal arguments in plpython functions

Well, I really don't like the idea of such a dependency. However it could be added as configuration option, so you could compile postgres with e.g. --with-cdecimal, and then it would be user dependent. Maybe it is a good idea for another patch. On 25 June 2013 14:23, Ronan Dunklau wrote: > Conc

[HACKERS] Hash partitioning.

Hi, Do we have any plans to implement Hash Partitioning, maybe I missing this feature? Sincerely yours, Yuri Levinsky, DBA Celltick Technologies Ltd., 32 Maskit St., Herzliya 46733, Israel Mobile: +972 54 6107703, Office: +972 9 9710239; Fax: +972 9 9710222 <>

Re: backend hangs at immediate shutdown (Re: [HACKERS] Back-branch update releases coming in a couple weeks)

From: "Alvaro Herrera" Yeah, I see that --- after removing that early exit, there are unwanted messages. And in fact there are some signals sent that weren't previously sent. Clearly we need something here: if we're in immediate shutdown handler, don't signal anyone (because they have already

Re: [HACKERS] Possible bug in CASE evaluation

On 2013-06-24 21:35:53 -0400, Noah Misch wrote: > On Sat, Jun 22, 2013 at 04:54:50PM +0200, Andres Freund wrote: > > On 2013-06-21 16:45:28 +0200, Andres Freund wrote: > > > On 2013-06-21 09:51:05 -0400, Noah Misch wrote: > > > > That being said, if we discover a simple-enough fix that performs wel

Re: [HACKERS] Possible bug in CASE evaluation

2013/6/25 Andres Freund : > On 2013-06-24 21:35:53 -0400, Noah Misch wrote: >> On Sat, Jun 22, 2013 at 04:54:50PM +0200, Andres Freund wrote: >> > On 2013-06-21 16:45:28 +0200, Andres Freund wrote: >> > > On 2013-06-21 09:51:05 -0400, Noah Misch wrote: >> > > > That being said, if we discover a sim

Re: [HACKERS] Hash partitioning.

On Tue, Jun 25, 2013 at 03:48:19PM +0300, Yuri Levinsky wrote: > Hi, > > Do we have any plans to implement Hash Partitioning, maybe I missing this > feature? You can do it by writing your own constraint and trigger functions that control the hashing. -- Bruce Momjian http://momjian.u

Re: [HACKERS] PostgreSQL 9.3 latest dev snapshot

On Tue, Jun 25, 2013 at 6:33 PM, Michael Paquier wrote: > On Tue, Jun 25, 2013 at 5:33 PM, Misa Simic wrote: >> Hi, >> >> Where we can find latest snapshot for 9.3 version? >> >> We have taken latest snapshot from >> http://ftp.postgresql.org/pub/snapshot/dev/ >> >> But it seems it is for 9.4 ver

Re: [HACKERS] Patch for fail-back without fresh backup

On Tue, Jun 25, 2013 at 12:19 PM, Pavan Deolasee wrote: > > > > On Mon, Jun 24, 2013 at 7:17 PM, Sawada Masahiko > wrote: >> >> >> >> >> [Server] >> standby_name = 'slave1' >> synchronous_transfer = commit >> wal_sender_timeout = 30 >> [Server] >> standby_name = 'slave2' >> s

Re: [HACKERS] PostgreSQL 9.3 latest dev snapshot

On 2013/06/25, at 22:23, Fujii Masao wrote: > On Tue, Jun 25, 2013 at 6:33 PM, Michael Paquier > wrote: >> On Tue, Jun 25, 2013 at 5:33 PM, Misa Simic wrote: >>> Hi, >>> >>> Where we can find latest snapshot for 9.3 version? >>> >>> We have taken latest snapshot from >>> http://ftp.postgresq

Re: FILTER for aggregates [was Re: [HACKERS] Department of Redundancy Department: makeNode(FuncCall) division]

Dean Rasheed writes: > On 24 June 2013 03:50, Tom Lane wrote: >> Going on the same principle, we could probably let FILTER be an >> unreserved keyword while FILTER_FOLLOWED_BY_PAREN could be a >> type_func_name_keyword. (I've not tried this though.) > I've not tried either, but wouldn't that me

Re: FILTER for aggregates [was Re: [HACKERS] Department of Redundancy Department: makeNode(FuncCall) division]

2013/6/25 Tom Lane : > Dean Rasheed writes: >> On 24 June 2013 03:50, Tom Lane wrote: >>> Going on the same principle, we could probably let FILTER be an >>> unreserved keyword while FILTER_FOLLOWED_BY_PAREN could be a >>> type_func_name_keyword. (I've not tried this though.) > >> I've not tried

Re: [HACKERS] proposal: enable new error fields in plpgsql (9.4)

Hello 2013/6/25 Rushabh Lathia : > Hi Pavel, > > I gone through the discussion over here and found that with this patch we > enable the new error fields in plpgsql. Its a simple patch to expose the new > error fields in plpgsql. > > Patch gets applied cleanly. make and make install too went smoo

Re: [HACKERS] Hash partitioning.

Bruce, Many thanks. According to PostgreSQL documentation it's only range and list partitions are supported. My question is: when I am following your advice, is PostgreSQL will do partitioning pruning on select? My expectation is: I divided my table on 128 hash partitions according let's say user_i

Re: [HACKERS] Hash partitioning.

On Tue, Jun 25, 2013 at 05:19:47PM +0300, Yuri Levinsky wrote: > Bruce, > Many thanks. According to PostgreSQL documentation it's only range and > list partitions are supported. My question is: when I am following your > advice, is PostgreSQL will do partitioning pruning on select? My > expectation

Re: FILTER for aggregates [was Re: [HACKERS] Department of Redundancy Department: makeNode(FuncCall) division]

On Sun, Jun 23, 2013 at 10:50 PM, Tom Lane wrote: > David Fetter writes: >> On Sun, Jun 23, 2013 at 07:44:26AM -0700, Kevin Grittner wrote: >>> I think it is OK if that gets a syntax error. If that's the "worst >>> case" I like this approach. > >> I think reducing the usefulness of error message

Re: [HACKERS] Hash partitioning.

On Tue, Jun 25, 2013 at 9:21 AM, Bruce Momjian wrote: > On Tue, Jun 25, 2013 at 03:48:19PM +0300, Yuri Levinsky wrote: >> Hi, >> >> Do we have any plans to implement Hash Partitioning, maybe I missing this >> feature? > > You can do it by writing your own constraint and trigger functions that > co

Re: [HACKERS] Hash partitioning.

On Tue, Jun 25, 2013 at 11:02:40AM -0400, Robert Haas wrote: > On Tue, Jun 25, 2013 at 9:21 AM, Bruce Momjian wrote: > > On Tue, Jun 25, 2013 at 03:48:19PM +0300, Yuri Levinsky wrote: > >> Hi, > >> > >> Do we have any plans to implement Hash Partitioning, maybe I missing this > >> feature? > > > >

Re: [HACKERS] Bugfix and new feature for PGXS

On 06/24/2013 07:24 PM, Cédric Villemain wrote: Le mardi 25 juin 2013 00:18:26, Andrew Dunstan a écrit : On 06/24/2013 04:02 PM, Cédric Villemain wrote: WIth extension, we do have to set VPATH explicitely if we want to use VPATH (note that contribs/extensions must not care that postgresql has

Re: [HACKERS] Bugfix and new feature for PGXS

Le mardi 25 juin 2013 17:18:51, Andrew Dunstan a écrit : > On 06/24/2013 07:24 PM, Cédric Villemain wrote: > > Le mardi 25 juin 2013 00:18:26, Andrew Dunstan a écrit : > >> On 06/24/2013 04:02 PM, Cédric Villemain wrote: > >>> WIth extension, we do have to set VPATH explicitely if we want to use >

Re: [HACKERS] GIN improvements part 3: ordering in index

On 25.06.2013 01:24, Alexander Korotkov wrote: On Wed, Jun 19, 2013 at 1:21 AM, Alexander Korotkovwrote: On Mon, Jun 17, 2013 at 10:27 PM, Heikki Linnakangas< hlinnakan...@vmware.com> wrote: That has some obvious limitations. First of all, you can run out of memory. Yes, it is so. qsort sh

Re: [HACKERS] Hash partitioning.

On Tue, Jun 25, 2013 at 11:06 AM, Bruce Momjian wrote: >> Not really. Constraint exclusion won't kick in for a constraint like >> CHECK (hashme(a) % 16 == 3) and a WHERE clause of the form a = 42. > > Uh, I thought we checked the constant against every CHECK constraint and > only scanned partiti

Re: [HACKERS] Fix pgstattuple/pgstatindex to use regclass-type as the argument

On Thu, Jun 20, 2013 at 2:32 PM, Fujii Masao wrote: > On Thu, Jun 20, 2013 at 11:43 AM, Satoshi Nagayasu wrote: >> (2013/06/17 4:02), Fujii Masao wrote: >>> >>> On Sat, Mar 9, 2013 at 3:23 PM, Satoshi Nagayasu wrote: It is obviously easy to keep two types of function interfaces, o

Re: [HACKERS] Hash partitioning.

On Tue, Jun 25, 2013 at 11:15:24AM -0400, Robert Haas wrote: > On Tue, Jun 25, 2013 at 11:06 AM, Bruce Momjian wrote: > >> Not really. Constraint exclusion won't kick in for a constraint like > >> CHECK (hashme(a) % 16 == 3) and a WHERE clause of the form a = 42. > > > > Uh, I thought we checked

Re: [HACKERS] C++ compiler

On 06/24/2013 09:16 PM, Tom Lane wrote: Bruce Momjian writes: Right. I don't think there are any C features we want to avoid; are there any? We're avoiding C99-and-later features that are not in C89, such as // for comments, as well as more useful things. It might be time to reconsider whe

Re: [HACKERS] Hash partitioning.

On Tue, Jun 25, 2013 at 11:45 AM, Bruce Momjian wrote: > On Tue, Jun 25, 2013 at 11:15:24AM -0400, Robert Haas wrote: >> On Tue, Jun 25, 2013 at 11:06 AM, Bruce Momjian wrote: >> >> Not really. Constraint exclusion won't kick in for a constraint like >> >> CHECK (hashme(a) % 16 == 3) and a WHERE

Re: [HACKERS] pgbench --startup option

On Thu, Jun 20, 2013 at 1:46 PM, Jeff Janes wrote: > I've fixed a conflict, and I've removed extraneous semicolons from the C. > > I've left in the fixing of some existing bad indenting in the existing code, > which is not strictly related to my change. OK, I like this idea a lot, but I have a qu

Re: [HACKERS] Support for REINDEX CONCURRENTLY

On Tue, Jun 25, 2013 at 8:15 AM, Michael Paquier wrote: > Patch updated according to comments. Thanks for updating the patch! When I ran VACUUM FULL, I got the following error. ERROR: attempt to apply a mapping to unmapped relation 16404 STATEMENT: vacuum full; Could you let me clear why toa

Re: [HACKERS] refresh materialized view concurrently

On Fri, Jun 21, 2013 at 5:20 AM, Hitoshi Harada wrote: > If I don't miss something, the requirement for the CONCURRENTLY option is to > allow simple SELECT reader to read the matview concurrently while the view > is populating the new data, and INSERT/UPDATE/DELETE and SELECT FOR > UPDATE/SHARE ar

Re: [HACKERS] Hash partitioning.

Bruce Momjian writes: > I looked at predtest.c but I can't see how we accept >= and <= ranges, > but not CHECK (a % 16 == 3). It is the '%' operator? I am not sure why > the hashme() function is there. Wouldn't it work if hashme() was an > immutable function? No. Robert's description is exact

Re: [HACKERS] Hash partitioning.

Guys, I am sorry for taking your time. The reason for my question is: As former Oracle DBA and now simple beginner PostgreSQL DBA I would like to say: the current partitioning mechanism might be improved. Sorry, it seems to me far behind yesterday requirements. As model for improvement the Oracle m

Re: [HACKERS] [PATCH] add long options to pgbench (submission 1)

On Thu, Jun 20, 2013 at 9:17 AM, Fabrízio de Royes Mello wrote: > On Thu, Jun 20, 2013 at 9:59 AM, Fabien COELHO wrote: >>> Please fix that and re-send the patch. >> Find attached diff wrt current master. > Thanks. I would like to solicit opinions on whether this is a good idea. I understand th

Re: [HACKERS] [PATCH] add long options to pgbench (submission 1)

On 2013-06-25 12:11:06 -0400, Robert Haas wrote: > On Thu, Jun 20, 2013 at 9:17 AM, Fabrízio de Royes Mello > wrote: > > On Thu, Jun 20, 2013 at 9:59 AM, Fabien COELHO wrote: > >>> Please fix that and re-send the patch. > >> Find attached diff wrt current master. > > Thanks. > > I would like to

Re: [HACKERS] isolationtester and 'specs' subdirectory

On Thu, Jun 20, 2013 at 7:10 PM, Josh Kupershmidt wrote: > I eventually tracked down the cause of this failure to a trailing ':' > in my $LIBRARY_PATH, which causes gcc to look inside the current > directory for a 'specs' file [1] among other things. Although I > probably don't need that trailing

Re: [HACKERS] [PATCH] add long options to pgbench (submission 1)

Robert Haas escribió: > On Thu, Jun 20, 2013 at 9:17 AM, Fabrízio de Royes Mello > wrote: > > On Thu, Jun 20, 2013 at 9:59 AM, Fabien COELHO wrote: > >>> Please fix that and re-send the patch. > >> Find attached diff wrt current master. > > Thanks. > > I would like to solicit opinions on whether

Re: [HACKERS] [PATCH] add long options to pgbench (submission 1)

Robert Haas writes: > I would like to solicit opinions on whether this is a good idea. I > understand that the patch author thinks it's a good idea, and I don't > have a strong position either way. But I want to hear what other > people think. If it makes pgbench more consistent with psql's com

Re: [HACKERS] Hash partitioning.

On Tue, Jun 25, 2013 at 12:08:34PM -0400, Tom Lane wrote: > Bruce Momjian writes: > > I looked at predtest.c but I can't see how we accept >= and <= ranges, > > but not CHECK (a % 16 == 3). It is the '%' operator? I am not sure why > > the hashme() function is there. Wouldn't it work if hashme(

Re: [HACKERS] pluggable compression support

On Thu, Jun 20, 2013 at 8:09 PM, Andres Freund wrote: > On 2013-06-15 12:20:28 +0200, Andres Freund wrote: >> On 2013-06-14 21:56:52 -0400, Robert Haas wrote: >> > I don't think we need it. I think what we need is to decide is which >> > algorithm is legally OK to use. And then put it in. >> > >

Re: [HACKERS] [PATCH] add long options to pgbench (submission 1)

On Tue, Jun 25, 2013 at 12:17 PM, Tom Lane wrote: > Robert Haas writes: >> I would like to solicit opinions on whether this is a good idea. I >> understand that the patch author thinks it's a good idea, and I don't >> have a strong position either way. But I want to hear what other >> people th

Re: [HACKERS] pg_filedump 9.3: checksums (and a few other fixes)

On Mon, 2013-06-24 at 20:34 -0400, Josh Kupershmidt wrote: > This patch is in the current CommitFest, does it still need to be > reviewed? If so, I notice that the version in pgfoundry's CVS is > rather different than the version the patch seems to have been built > against (presumably the pg_filed

Re: [HACKERS] Improvement of checkpoint IO scheduler for stable transaction responses

On 21.06.2013 11:29, KONDO Mitsumasa wrote: I took results of my separate patches and original PG. * Result of DBT-2 | TPS 90%tile Average Maximum -- original_0.7 | 3474.62 18.348328 5.739 36.977713 original_1.0 | 3469.03 18.637865 5.842 41.754

[HACKERS] Kudos for Reviewers -- straw poll

Hackers, I'd like to take a straw poll here on how we should acknowledge reviewers. Please answer the below with your thoughts, either on-list or via private email. How should reviewers get credited in the release notes? a) not at all b) in a single block titled "Reviewers for this version" at

Re: [HACKERS] Clean switchover

On Mon, Jun 24, 2013 at 3:41 PM, Andres Freund wrote: > On 2013-06-14 04:56:15 +0900, Fujii Masao wrote: >> On Wed, Jun 12, 2013 at 9:48 PM, Stephen Frost wrote: >> > * Magnus Hagander (mag...@hagander.net) wrote: >> >> On Wed, Jun 12, 2013 at 1:48 PM, Andres Freund >> >> wrote: >> >> > On 2013

Re: [HACKERS] Kudos for Reviewers -- straw poll

On 25.06.2013 20:17, Josh Berkus wrote: Hackers, I'd like to take a straw poll here on how we should acknowledge reviewers. Please answer the below with your thoughts, either on-list or via private email. How should reviewers get credited in the release notes? a) not at all b) in a single blo

Re: [HACKERS] Kudos for Reviewers -- straw poll

On Tue, June 25, 2013 19:17, Josh Berkus wrote: > How should reviewers get credited in the release notes? b) in a single block titled "Reviewers for this version" at the bottom. > Should there be a criteria for a "creditable" review? b) yes, they have to do more than "it compiles" > Should re

Re: [HACKERS] request a new feature in fuzzystrmatch

On Mon, Jun 24, 2013 at 6:02 PM, Joe Conway wrote: > -BEGIN PGP SIGNED MESSAGE- > Hash: SHA1 > > On 06/14/2013 12:08 PM, Liming Hu wrote: I have implemented the code according to Joe's suggestion, and put the code at: https://github.com/liminghu/fuzzystrmatch/tre

Re: [HACKERS] Review: Patch to compute Max LSN of Data Pages

Hi, On 2013-06-16 17:19:49 -0700, Josh Berkus wrote: > Amit posted a new version of this patch on January 23rd. But last > comment on it by Tom is "not sure everyone wants this". > > https://commitfest.postgresql.org/action/patch_view?id=905 > ... so, what's the status of this patch? That comm

Re: [HACKERS] Kudos for Reviewers -- straw poll

On 2013-06-25 10:17:07 -0700, Josh Berkus wrote: > How should reviewers get credited in the release notes? > > a) not at all > b) in a single block titled "Reviewers for this version" at the bottom. > c) on the patch they reviewed, for each patch b). If the review was substantial enough the revi

Re: [HACKERS] Kudos for Reviewers -- straw poll

On 06/25/2013 10:46 AM, Andres Freund wrote: > Not sure. Seems like it might be a way to spend a lot of effort without > achieving all that much. But I can also imagine that it feels nice and > encourages a casual reviewer/contributor. > > So it's either b) or c). Although I'd perhaps exclude regu

Re: [HACKERS] INTERVAL overflow detection is terribly broken

So, any insights on these problems? They might not be critical, but might be silently corrupting someone's data. 2013/6/23 Rok Kralj > Hi, after studying ITERVAL and having a long chat with RhoidumToad and > StuckMojo on #postgresql, I am presenting you 3 bugs regarding INTERVAL. > > As far as

Re: [HACKERS] Kudos for Reviewers -- straw poll

On 06/25/2013 10:17 AM, Josh Berkus wrote: Hackers, I'd like to take a straw poll here on how we should acknowledge reviewers. Please answer the below with your thoughts, either on-list or via private email. How should reviewers get credited in the release notes? a) not at all b) in a singl

Re: [HACKERS] Hash partitioning.

Yuri Levinsky escribió: > As former Oracle DBA and now simple beginner PostgreSQL DBA I would like > to say: the current partitioning mechanism might be improved. Sorry, it > seems to me far behind yesterday requirements. I don't think you'll find anybody that disagrees with this. -- Álvaro Her

Re: [HACKERS] Hash partitioning.

On Tue, Jun 25, 2013 at 12:55 PM, Robert Haas wrote: > Let me back up a minute. You told the OP that he could make hash > partitioning by writing his own constraint and trigger functions. I > think that won't work. But I'm happy to be proven wrong. Do you have > an example showing how to do it

Re: [HACKERS] GIN improvements part 3: ordering in index

On Tue, Jun 25, 2013 at 7:31 PM, Heikki Linnakangas wrote: > On 25.06.2013 01:24, Alexander Korotkov wrote: > >> On Wed, Jun 19, 2013 at 1:21 AM, Alexander Korotkov >> **wrote: >> >> On Mon, Jun 17, 2013 at 10:27 PM, Heikki Linnakangas< >>> hlinnakan...@vmware.com> wrote: >>> >>> That has some

Re: [HACKERS] pgbench --startup option

OK, I like this idea a lot, but I have a question. Right now, to use this, you have to supply the startup SQL on the command line. And that could definitely be useful. But ISTM that you might also want to take the startup SQL from a file, and indeed you might well want to include metacommands

Re: [HACKERS] Kudos for Reviewers -- straw poll

On 2013-06-25 11:04:38 -0700, Joshua D. Drake wrote: > >a) not at all > >b) in a single block titled "Reviewers for this version" at the bottom. > >c) on the patch they reviewed, for each patch > > C. The idea that reviewers are somehow less than authors is rather > disheartening. It's not about

Re: [HACKERS] Kudos for Reviewers -- straw poll

On 06/25/2013 01:17 PM, Josh Berkus wrote: Hackers, I'd like to take a straw poll here on how we should acknowledge reviewers. Please answer the below with your thoughts, either on-list or via private email. How should reviewers get credited in the release notes? a) not at all b) in a single

Re: [HACKERS] pluggable compression support

On 2013-06-25 12:22:31 -0400, Robert Haas wrote: > On Thu, Jun 20, 2013 at 8:09 PM, Andres Freund wrote: > > On 2013-06-15 12:20:28 +0200, Andres Freund wrote: > >> On 2013-06-14 21:56:52 -0400, Robert Haas wrote: > >> > I don't think we need it. I think what we need is to decide is which > >> >

Re: [HACKERS] Kudos for Reviewers -- straw poll

On Tue, Jun 25, 2013 at 2:17 PM, Josh Berkus wrote: > How should reviewers get credited in the release notes? > c) on the patch they reviewed, for each patch This not only makes sense, it also lets people reading release notes know there's been a review, and how thorough it was. I know, all chang

Re: [HACKERS] Kudos for Reviewers -- straw poll

On 06/25/2013 11:26 AM, Andres Freund wrote: > On 2013-06-25 11:04:38 -0700, Joshua D. Drake wrote: >>> a) not at all >>> b) in a single block titled "Reviewers for this version" at the bottom. >>> c) on the patch they reviewed, for each patch >> >> C. The idea that reviewers are somehow less than

Re: [HACKERS] Kudos for Reviewers -- straw poll

On 06/25/2013 11:26 AM, Andres Freund wrote: On 2013-06-25 11:04:38 -0700, Joshua D. Drake wrote: a) not at all b) in a single block titled "Reviewers for this version" at the bottom. c) on the patch they reviewed, for each patch C. The idea that reviewers are somehow less than authors is ra

Re: [HACKERS] Hash partitioning.

On Tue, Jun 25, 2013 at 12:08 PM, Yuri Levinsky wrote: > Guys, > I am sorry for taking your time. The reason for my question is: > As former Oracle DBA and now simple beginner PostgreSQL DBA I would like > to say: the current partitioning mechanism might be improved. Sorry, it > seems to me far b

Re: [HACKERS] pluggable compression support

On 06/25/2013 11:42 AM, Andres Freund wrote: > True. So, how do we proceed on that? > > The ASF decided it was safe to use lz4 in cassandra. Does anybody have > contacts over there? > > Btw, I have the feeling we hold this topic to a higher standard wrt > patent issues than other work in postgres

Re: [HACKERS] [PATCH] add long options to pgbench (submission 1)

I think I'd like to quibble with some of the names a bit, though. That is a good idea, because I'm not a native English speaker and I was not so sure for many options. The patch adds --fill-factor, but I think we should spell it without the hyphen: --fillfactor. Fine with me. I think -

Re: [HACKERS] pluggable compression support

On 2013-06-25 12:08:22 -0700, Josh Berkus wrote: > On 06/25/2013 11:42 AM, Andres Freund wrote: > > True. So, how do we proceed on that? > > > > The ASF decided it was safe to use lz4 in cassandra. Does anybody have > > contacts over there? > > > > Btw, I have the feeling we hold this topic to a

Re: [HACKERS] pluggable compression support

On Tue, Jun 25, 2013 at 4:15 PM, Andres Freund wrote: >> However, can you tell me what exactly you are concerned about? lz4 is >> under the BSD license, and released by Google. > > Snappy is released/copyrighted by google. lz4 by Yann Collet. > > Both are under BSD licenses (3 and 2 clause variant

Re: [HACKERS] pluggable compression support

Josh Berkus writes: > However, can you tell me what exactly you are concerned about? lz4 is > under the BSD license, and released by Google. Why are we worried, exactly? Patents. The license on the code doesn't matter --- worst case, if someone objected, we could rewrite the algorithm ourselves

Re: [HACKERS] Kudos for Reviewers -- straw poll

On 25 June 2013 18:17, Josh Berkus wrote: > Hackers, > > I'd like to take a straw poll here on how we should acknowledge > reviewers. Please answer the below with your thoughts, either on-list > or via private email. > > How should reviewers get credited in the release notes? > > a) not at all >

Re: [HACKERS] pluggable compression support

On 06/25/2013 12:23 PM, Tom Lane wrote: > Josh Berkus writes: >> However, can you tell me what exactly you are concerned about? lz4 is >> under the BSD license, and released by Google. Why are we worried, exactly? > > Patents. The license on the code doesn't matter --- worst case, if > someone

Re: [HACKERS] Kudos for Reviewers -- straw poll

On Tue, Jun 25, 2013 at 10:17:07AM -0700, Josh Berkus wrote: > Hackers, > > I'd like to take a straw poll here on how we should acknowledge > reviewers. Please answer the below with your thoughts, either on-list > or via private email. > > How should reviewers get credited in the release notes?

Re: [HACKERS] Hash partitioning.

Christopher Browne writes: > There would indeed be merit in improving the partitioning apparatus, > and actually, I think it's been a couple of years since there has been > serious discussion of this. We could certainly use a partitioning mechanism that's easier to use than what we have now, whic

[HACKERS] LATERAL quals revisited

I've been studying the bug reported at http://www.postgresql.org/message-id/20130617235236.GA1636@jeremyevans.local that the planner can do the wrong thing with queries like SELECT * FROM i LEFT JOIN LATERAL (SELECT * FROM j WHERE i.n = j.n) j ON true; I think the fundamental problem is that, b

Re: [HACKERS] Improvement of checkpoint IO scheduler for stable transaction responses

On Tue, Jun 25, 2013 at 1:15 PM, Heikki Linnakangas wrote: > I'm not sure it's a good idea to sleep proportionally to the time it took to > complete the previous fsync. If you have a 1GB cache in the RAID controller, > fsyncing the a 1GB segment will fill it up. But since it fits in cache, it > wi

Re: [HACKERS] Improvement of checkpoint IO scheduler for stable transaction responses

On 25.06.2013 23:03, Robert Haas wrote: On Tue, Jun 25, 2013 at 1:15 PM, Heikki Linnakangas wrote: I'm not sure it's a good idea to sleep proportionally to the time it took to complete the previous fsync. If you have a 1GB cache in the RAID controller, fsyncing the a 1GB segment will fill it u

Re: [HACKERS] Hash partitioning.

On Tue, Jun 25, 2013 at 4:32 PM, Tom Lane wrote: > However, I find it hard to think that hash partitioning as such is very > high on the to-do list. As was pointed out upthread, the main practical > advantage of partitioning is *not* performance of routine queries, but > improved bulk-data manage

Re: [HACKERS] Optimizing pglz compressor

On 19.06.2013 14:01, Amit Kapila wrote: Observations -- 1. For small data perforamce is always good with patch. 2. For random small/large data performace is good. 3. For medium and large text and same byte data(3K,5K text, 10K,100K,500K same byte), performance is degraded. Wow, that

Re: [HACKERS] XLogInsert scaling, revisited

On Sat, Jun 22, 2013 at 4:32 AM, Heikki Linnakangas wrote: > On 21.06.2013 21:55, Jeff Janes wrote: > >> >> Hmm, it looks like the xlog-switch is trying to wait for itself to > finish. The concurrent TRUNCATE is just being blocked behind the > xlog-switch, which is stuck on itself. > > I wasn't a

[HACKERS] Review: query result history in psql

Hi Maciej, I've been reviewing your patch for the ongoing commitfest. First let me say that I think it's a great idea and provides some very useful functionality. However, there are a few minor problems. There were a few english/grammatical mistakes that I went ahead and fixed. Additionally, I th

Re: [HACKERS] LATERAL quals revisited

(Please excuse me if my proposal sounds silly, i'm still not too advanced in this area...) On 06/25/2013 10:00 PM, Tom Lane wrote: After some contemplation, I think that the most practical way to fix this is for deconstruct_recurse and distribute_qual_to_rels to effectively move such a qual to

Re: [HACKERS] Hash partitioning.

Claudio Freire wrote: > Did you try "select * from foo where (a % 16) = (1::int % 16)"? I did.  Using Robert's hashed partitioning table definitions: test=# explain select * from foo where a = 1 and (a % 16) = (1 % 16); QUERY PLAN     ---

Re: [HACKERS] LATERAL quals revisited

Antonin Houska writes: > On 06/25/2013 10:00 PM, Tom Lane wrote: >> After some contemplation, I think that the most practical way to fix >> this is for deconstruct_recurse and distribute_qual_to_rels to >> effectively move such a qual to the place where it logically belongs; >> that is, rather tha

  1   2   >