Re: [HACKERS] Cube extension point support // GSoC'13

On 12.07.2013 14:57, Stas Kelvich wrote: Hello. here is a patch adding to cube extension support for compressed representation of point cubes. If cube is a point, i.e. has coincident lower left and upper right corners, than only one corner is stored. First bit of the cube header indicates whe

Re: [HACKERS] [PATCH] Statistics collection for CLUSTER command

(2013/08/08 20:52), Vik Fearing wrote: As part of routine maintenance monitoring, it is interesting for us to have statistics on the CLUSTER command (timestamp of last run, and number of runs since stat reset) like we have for (auto)ANALYZE and (auto)VACUUM. Patch against today's HEAD attached.

Re: [HACKERS] \h open

On 16.09.2013 07:43, Oleg Bartunov wrote: I noticed there is nothing available in built-in psql help about OPEN command. Does it intentional ? That's because there is no OPEN command. PL/pgSQL does have an OPEN statement, but that's just PL/pgSQL. And ecpg too, but again that's handled by ecp

Re: [HACKERS] plpgsql.print_strict_params

2013/9/15 Marko Tiikkaja : > > Attached an updated patch to fix the tabs and to change this to a > compile-time option. Now it's not possible to flexibly disable the feature > during runtime, but I think that's fine. I'm taking a look at this patch as part of the current commitfest [*], (It's the

Re: [HACKERS] Hstore: Query speedups with Gin index

Blake, I've taken the liberty of adding this patch to the current Commitfest. In future, please continue to send patches both to this thread and to the commitfest application when you have a message ID for them :) Cheers, David. On Mon, Sep 09, 2013 at 09:55:01AM -0500, Blake Smith wrote: > Than

Re: [HACKERS] pg_system_identifier()

Hi, I'm catching up with the discussion as a reviewer... (2013/08/27 5:35), Tom Lane wrote: > Andres Freund writes: >> On 2013-08-26 10:10:54 -0700, Josh Berkus wrote: >>> I'm going to reverse my vote, and vote against this patch. The reason >>> why is that I think we should instead have a func

Re: [HACKERS] [PATCH] bitmap indexes

Hi Jaime. At 2013-09-15 23:32:11 -0500, ja...@2ndquadrant.com wrote: > > bitmapxlog.c:658:32: warning: ‘reln’ may be used uninitialized in this > function [-Wuninitialized] I added an XXX comment about this one, will investigate and fix. Will look into the other errors as well, many thanks for t

Re: [HACKERS] PL/pgSQL, RAISE and error context

On Sun, 2013-09-15 at 14:28 +0200, Marko Tiikkaja wrote: > On 15/09/2013 13:58, I wrote: > > Hmm. I just noticed there's something weird going on in the select_view > > test. I'm investigating this currently. > > Seems that there's some magic going on and I overwrote the expected > results of t

Re: [HACKERS] GIN improvements part 1: additional information

Please fix compiler warnings: gindatapage.c: In function ‘dataPlaceToPage’: gindatapage.c:706:24: warning: unused variable ‘pageBackup’ [-Wunused-variable] gindatapage.c: In function ‘updateItemIndexes’: gindatapage.c:1182:6: warning: variable ‘totalsize’ set but not used [-Wunused-but-set-variab

Re: [HACKERS] git apply vs patch -p1

On Sun, Sep 15, 2013 at 12:38 AM, Andres Freund wrote: > On 2013-09-14 15:03:52 -0400, Andrew Dunstan wrote: > > > > On 09/14/2013 02:37 PM, Josh Berkus wrote: > > >Folks, > > > > > >Lately I've been running into a lot of reports of false conflicts > > >reported by "git apply". The most recent on

[HACKERS] \h open

I noticed there is nothing available in built-in psql help about OPEN command. Does it intentional ? postgres=# \h open No help available for "open". Try \h with no arguments to see available help. Oleg

Re: [HACKERS] [PATCH] bitmap indexes

On Sat, Sep 14, 2013 at 1:14 PM, Abhijit Menon-Sen wrote: > Hi. > > This is a cleaned-up and rebased version of the bitmap index patch from > Gavin Sherry, later revised by Gianni Ciolli and Gabriele Bartolini, and > others including Daniel Bausch. > Hi Abhijit, Please, in the next update consid

Re: [HACKERS] [PoC] pgstattuple2: block sampling to reduce physical read

(2013/09/15 11:07), Peter Eisentraut wrote: On Sat, 2013-09-14 at 16:18 +0900, Satoshi Nagayasu wrote: I'm looking forward to seeing more feedback on this approach, in terms of design and performance improvement. So, I have submitted this for the next CF. Your patch fails to build: pgstattupl

Re: [HACKERS] Proposal: json_populate_record and nested json objects

> On 15 September 2013 at 18:42 Andrew Dunstan wrote: > > > > On 09/14/2013 10:27 PM, chris travers wrote: > > Well, you could fairly easily build it as an extension as a POC. The > main point of the API this is built on was to allow for extensions. > > The logic changes might be a bit tricky. I

Re: [HACKERS] Commitfest II, 9.4 edition

2013/9/16 David Fetter : > has begun! > > New hackers, this is your chance to contribute by doing the first few > steps of review. Seasoned hackers, this is a way to help the whole > project along. You know the drill. > > Too many patches have "Nobody" today. That's the first thing we'll > need

Re: [HACKERS] record identical operator

On 09/15/2013 01:35 PM, Kevin Grittner wrote: > Andres Freund wrote: > >> If matview refreshs weren't using plain SQL and thus wouldn't >> require exposing that operator to SQL I wouldn't have a problem >> with this... > If RMVC were the end of the story, it might be worth building up a > mass of

[HACKERS] Re: [HACKERS] Re: [HACKERS] Re: [HACKERS] Re: [HACKERS] Is it necessary to rewrite table while increasing the scale of datatype numeric？

On Fri, Sep 6, 2013 at 11:47 AM, Tom Lane wrote: > Robert Haas writes: > > Sure, but the point is that 5. is not the same as 5.000 today. If > > you start whacking this around you'll be changing that behavior, I > > think. > > Yeah. And please note that no matter what the OP may think, a l

Re: [HACKERS] Where to load modules from?

On 09/15/2013 05:52 PM, Jeff Janes wrote: On Sun, Sep 15, 2013 at 6:51 AM, Peter Eisentraut > wrote: On Sat, 2013-09-14 at 22:15 +0200, Dimitri Fontaine wrote: > > This proposal comes with no patch because I think we are able to > understand it without th

Re: [HACKERS] record identical operator

On Sat, Sep 14, 2013 at 08:58:32PM +0200, Andres Freund wrote: > On 2013-09-14 11:25:52 -0700, Kevin Grittner wrote: > > Andres Freund wrote: > > > But both arrays don't have the same binary representation since > > > the former has a null bitmap, the latter not. So, if you had a > > > composite t

Re: [HACKERS] Assertions in PL/PgSQL

El 15/09/2013 17:13, "Marko Tiikkaja" escribió: > > On 2013-09-15 23:23, Jaime Casanova wrote: >> >> If using ASSERT as keyword is not acceptable, not that i agree but in case. >> What about using RAISE EXCEPTION WHEN (condition) > > > I think it would be extremely surprising if a command like tha

Re: [HACKERS] Assertions in PL/PgSQL

On 2013-09-15 23:23, Jaime Casanova wrote: If using ASSERT as keyword is not acceptable, not that i agree but in case. What about using RAISE EXCEPTION WHEN (condition) I think it would be extremely surprising if a command like that got optimized away based on a GUC, so I don't think that woul

Re: [HACKERS] Where to load modules from?

On Sun, Sep 15, 2013 at 6:51 AM, Peter Eisentraut wrote: > On Sat, 2013-09-14 at 22:15 +0200, Dimitri Fontaine wrote: > > > > This proposal comes with no patch because I think we are able to > > understand it without that, so that it would only be a waste of > > everybody's time to attach code fo

Re: [HACKERS] Assertions in PL/PgSQL

El 14/09/2013 15:25, "Pavel Stehule" escribió: > > Hello > > There is a significant issue - new reserved keyword. There is high probability so lot of users has a functions named "assert". > > I like this functionality, but I dislike any compatibility break for feature, that can be implemented as e

[HACKERS] [Review] Effectiveness of enable_material = off

Before getting to the administrivia of the patch review, I think it's worth a bit of analysis on why the planner behaves as it does. The example query: explain analyze select * from ( select oid, * from pg_class order by oid) as c join ( select * from pg_attribute a order by attrelid)

Re: [HACKERS] Proposal: json_populate_record and nested json objects

On 09/14/2013 10:27 PM, chris travers wrote: Hi all; Currently json_populate_record and json_populate_recordset cannot work with nested json objects. This creates two fundamental problems when trying to use JSON as an interface format. The first problem is you can't easily embed a json data t

Re: [HACKERS] PL Code Archive Proposal

Peter Eisentraut writes: > You added this to the commit fest, but there is no patch attached. I > don't think you have a patch yet. My intention is to work on a patch only after getting some feedback and possibly a consensus, if enough people are interested in fixing the problem. Meanwhile, ent

Re: [HACKERS] Where to load modules from?

Peter Eisentraut writes: > Post it to the pgsql-hackers list. Well. I think I just did ;-) > I understand why using the commit fest process is attractive for this, > because it enables you to force the issue. But the point of the commit It enables me to have a slight chance of seeing the effor

Re: [HACKERS] [PATCH] pg_upgrade: Split off pg_fatal() from pg_log()

Hi Peter, On 2013-09-13 04:50, Peter Eisentraut wrote: The experiences with elog() and ereport() have shown that having one function that can return or not depending on some log level parameter isn't a good idea when you want to communicate well with the compiler. In pg_upgrade, there is a simil

Re: [HACKERS] Where to load modules from?

On 2013-09-15 17:03:10 +0200, Marko Tiikkaja wrote: > On 2013-09-15 16:51, Peter Eisentraut wrote: > >On Sun, 2013-09-15 at 16:09 +0200, Dimitri Fontaine wrote: > >>My understanding is that a Commit Fest is mainly about Reviewing, that's > >>why I still added an entry for two designs that I need fe

[HACKERS] Commitfest II, 9.4 edition

has begun! New hackers, this is your chance to contribute by doing the first few steps of review. Seasoned hackers, this is a way to help the whole project along. You know the drill. Too many patches have "Nobody" today. That's the first thing we'll need to fix, one way or another. Let's make

Re: [HACKERS] logical changeset generation v6

On 2013-09-15 11:20:20 -0400, Peter Eisentraut wrote: > On Sat, 2013-09-14 at 22:49 +0200, Andres Freund wrote: > > Attached you can find the newest version of the logical changeset > > generation patchset. > > You probably have bigger things to worry about, but please check the > results of cplus

Re: [HACKERS] Minmax indexes

On Sat, 2013-09-14 at 21:14 -0300, Alvaro Herrera wrote: > Here's a reviewable version of what I've dubbed Minmax indexes. Please fix duplicate OID 3177. -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpr

Re: [HACKERS] INSERT...ON DUPLICATE KEY LOCK FOR UPDATE

On 2013-09-15 02:19:41 -0700, Peter Geoghegan wrote: > On Sat, Sep 14, 2013 at 1:57 AM, Greg Stark wrote: > > It seems to me that the nature of the problem is that there will unavoidably > > be a nexus between the two parts of the code here. We can try to isolate it > > as much as possible but we'

Re: [HACKERS] logical changeset generation v6

On Sat, 2013-09-14 at 22:49 +0200, Andres Freund wrote: > Attached you can find the newest version of the logical changeset > generation patchset. You probably have bigger things to worry about, but please check the results of cpluspluscheck, because some of the header files don't include header f

Re: [HACKERS] Where to load modules from?

On 2013-09-15 16:51, Peter Eisentraut wrote: On Sun, 2013-09-15 at 16:09 +0200, Dimitri Fontaine wrote: My understanding is that a Commit Fest is mainly about Reviewing, that's why I still added an entry for two designs that I need feedback on before actually coding a solution. Writing the code

Re: [HACKERS] INSERT...ON DUPLICATE KEY LOCK FOR UPDATE

Peter Geoghegan wrote: > There is no reason to call CheckForSerializableConflictIn() with > the additional locks held either. After all, "For a heap insert, > we only need to check for table-level SSI locks". You're only talking about not covering that call with a *new* LWLock, right?  We put so

Re: [HACKERS] Where to load modules from?

On Sun, 2013-09-15 at 16:09 +0200, Dimitri Fontaine wrote: > Peter Eisentraut writes: > > It shouldn't be in the commit fest if it has no patch. > > What should I do if my goal is to get community consensus on the best > way to solve a problem, and want to start the discussion with some > proposa

Re: [HACKERS] Assertions in PL/PgSQL

On 2013-09-15 16:34, Peter Eisentraut wrote: On Sat, 2013-09-14 at 20:47 +0200, Marko Tiikkaja wrote: Attached is a patch for supporting assertions in PL/PgSQL. These are similar to the Assert() backend macro: they can be disabled during compile time, but when enabled, abort execution if the pa

Re: [HACKERS] Assertions in PL/PgSQL

On Sat, 2013-09-14 at 20:47 +0200, Marko Tiikkaja wrote: > Attached is a patch for supporting assertions in PL/PgSQL. These are > similar to the Assert() backend macro: they can be disabled during > compile time, but when enabled, abort execution if the passed expression > is not true. Doesn't

Re: [HACKERS] INSERT...ON DUPLICATE KEY LOCK FOR UPDATE

On 15 Sep 2013 10:19, "Peter Geoghegan" wrote: > > On Sat, Sep 14, 2013 at 1:57 AM, Greg Stark wrote: > > It seems to me that the nature of the problem is that there will unavoidably > > be a nexus between the two parts of the code here. We can try to isolate it > > as much as possible but we're

Re: [HACKERS] Where to load modules from?

Peter Eisentraut writes: > It shouldn't be in the commit fest if it has no patch. What should I do if my goal is to get community consensus on the best way to solve a problem, and want to start the discussion with some proposals? My understanding is that a Commit Fest is mainly about Reviewing,

Re: [HACKERS] logical changeset generation v6

On 2013-09-15 10:03:54 -0400, Peter Eisentraut wrote: > What's with 0001-Improve-regression-test-for-8410.patch? Did you mean > to include that? Gah, no. That's already committed and unrelated. Stupid wildcard. Greetings, Andres Freund -- Andres Freund http://www.2ndQuadr

Re: [HACKERS] GUC for data checksums

On 2013-09-15 03:34:53 +0200, Bernd Helmle wrote: > > > --On 15. September 2013 00:25:34 +0200 Andres Freund > wrote: > > >Looks like a good idea to me. The implementation looks sane as well, > >except that I am not sure if we really need to introduce that faux > >variable. If the variable cann

Re: [HACKERS] logical changeset generation v6

What's with 0001-Improve-regression-test-for-8410.patch? Did you mean to include that? -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers

Re: [HACKERS] Where to load modules from?

On Sat, 2013-09-14 at 22:15 +0200, Dimitri Fontaine wrote: > > This proposal comes with no patch because I think we are able to > understand it without that, so that it would only be a waste of > everybody's time to attach code for a random solution on the list here > to that email. It shouldn't

Re: [HACKERS] PL Code Archive Proposal

You added this to the commit fest, but there is no patch attached. I don't think you have a patch yet. -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers

Re: [HACKERS] PL/pgSQL, RAISE and error context

On 15/09/2013 13:50, I wrote: On 15/09/2013 04:05, Peter Eisentraut wrote: On Sat, 2013-09-14 at 04:58 +0200, Marko Tiikkaja wrote: The attached patch (based on Pavel's patch) changes the default to be slightly more verbose (the CONTEXT lines which were previously omitted will be visible), but

Re: [HACKERS] plpgsql.print_strict_params

On 15/09/2013 04:02, Peter Eisentraut wrote: On Fri, 2013-09-13 at 23:56 +0200, Marko Tiikkaja wrote: Attached is a patch for optionally printing more information on STRICT failures in PL/PgSQL: Please fix the tabs in the SGML files. Oops. Thanks. Attached an updated patch to fix the tabs

Re: [HACKERS] record identical operator

Andres Freund wrote: > If matview refreshs weren't using plain SQL and thus wouldn't > require exposing that operator to SQL I wouldn't have a problem > with this... If RMVC were the end of the story, it might be worth building up a mass of execution nodes directly, although it would be hard to

Re: [HACKERS] INSERT...ON DUPLICATE KEY LOCK FOR UPDATE

On Sat, Sep 14, 2013 at 1:57 AM, Greg Stark wrote: > It seems to me that the nature of the problem is that there will unavoidably > be a nexus between the two parts of the code here. We can try to isolate it > as much as possible but we're going to need a bit of a compromise. Exactly. That's why

Re: [HACKERS] GIN improvements part 1: additional information

On Sat, Jun 29, 2013 at 12:56 PM, Heikki Linnakangas < hlinnakan...@vmware.com> wrote: > There's a few open questions: > > 1. How are we going to handle pg_upgrade? It would be nice to be able to > read the old page format, or convert on-the-fly. OTOH, if it gets too > complicated, might not be wo

Re: [HACKERS] Minor inheritance/check bug: Inconsistent behavior

Bruce Momjian wrote: On Sun, Jun 30, 2013 at 06:57:10AM +, Amit kapila wrote: >> >> I have done the initial analysis and prepared a patch, don't know if >> >> anything more I can do until >> >> someone can give any suggestions to further proceed on this bug. > > > >So, I guess we never figured