Re: [HACKERS] pg_class.relpages/allvisible probably shouldn't be a int4

On Fri, May 9, 2014 at 1:50 PM, Andres Freund wrote: > And adding a proper unsigned type doesn't sound like a small amount of work. Perhaps not, but it's overdue. We ought to have one. -- Peter Geoghegan -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to

Re: [HACKERS] 9.5: UPDATE/DELETE .. ORDER BY .. LIMIT ..

On Thu, Mar 13, 2014 at 3:49 AM, Rukh Meski wrote: > Oops. Of course shouldn't try and change how INSERT works. Latest version > attached. I had given a brief look into this patch and found that the implementation for Update .. ORDER BY is not appropriate for inheritance tables. It just tries

Re: [HACKERS] postgresql.auto.conf read from wrong directory

On Sun, May 11, 2014 at 4:38 AM, Fujii Masao wrote: > ISTM that data_directory is in different situation from the other. That is, > setting data_directory in postgresql.auto.conf is problematic whether its > setting value is valid or invalid. Imagine the case where data_directory > is set to '/dat

Re: [HACKERS] default opclass for jsonb (was Re: Call for GIST/GIN/SP-GIST opclass documentation)

Peter Geoghegan writes: > On Sat, May 10, 2014 at 5:54 PM, Tom Lane wrote: >> + especially if >> + there are a very large number of rows containing any single one of the >> + three keys > I suggest that you phrase this as "three index items". Good idea --- "key" is overloaded in thi

Re: [HACKERS] default opclass for jsonb (was Re: Call for GIST/GIN/SP-GIST opclass documentation)

On Sat, May 10, 2014 at 5:54 PM, Tom Lane wrote: > I'm not sure whether we have consensus to rename jsonb_hash_ops to > jsonb_path_ops, but since time is so short I went ahead and made a draft > patch to do so (attached). Probably the most interesting part of this is > the new text in json.sgml e

Re: [HACKERS] default opclass for jsonb (was Re: Call for GIST/GIN/SP-GIST opclass documentation)

Peter Geoghegan writes: > Now, I'm not all that worried about this, because this is surely an > odd-ball use case, particularly for jsonb_hash_ops where no keys are > separately indexed (separately from *primitive* elements/values). > However, it is worth noting in the documentation in my view. I

Re: [HACKERS] default opclass for jsonb (was Re: Call for GIST/GIN/SP-GIST opclass documentation)

On Sat, May 10, 2014 at 2:52 PM, Peter Geoghegan wrote: > I've added a wildcard to the rhs jsonb here, which of course won't > work, the proximate cause being that that simply isn't valid jsonb. > It's also something inherently impossible to support with the current > jsonb_hash_op's indexing stra

Re: [HACKERS] New pg_lsn type doesn't have hash/btree opclasses

On Sun, May 11, 2014 at 8:17 AM, Andres Freund wrote: > Anyway. I accept it's too late for beta1 now. Let's commit it if there's > another catversion bump. +1. Let's rely on the experience of senior committers here. -- Michael -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.or

Re: [HACKERS] New pg_lsn type doesn't have hash/btree opclasses

On Sat, May 10, 2014 at 9:45 PM, Fabrízio de Royes Mello wrote: > Last night I sent a patch [1] to add more tests and change the operator > name. Maybe we can merge the test cases... ;-) Sure, I noticed that. But I think that they are more complicated than necessary. I am as well doubtful about ad

Re: [HACKERS] New pg_lsn type doesn't have hash/btree opclasses

On 2014-05-10 19:08:48 -0400, Tom Lane wrote: > Magnus Hagander writes: > > On Sun, May 11, 2014 at 12:27 AM, Andres Freund > > wrote: > >> The problem is that once the beta is in progress (starting tomorrow), > >> the projects tries to avoid changes which require a dump and restore (or > >> pg_u

Re: [HACKERS] New pg_lsn type doesn't have hash/btree opclasses

Magnus Hagander writes: > On Sun, May 11, 2014 at 12:27 AM, Andres Freund wrote: >> The problem is that once the beta is in progress (starting tomorrow), >> the projects tries to avoid changes which require a dump and restore (or >> pg_upgrade). Since the patch changes the catalog it'd require tha

Re: [HACKERS] postgresql.auto.conf read from wrong directory

On Sat, May 10, 2014 at 12:30 PM, Amit Kapila wrote: > On Fri, May 9, 2014 at 7:01 PM, Fujii Masao wrote: >> On Fri, May 9, 2014 at 1:06 PM, Amit Kapila wrote: >>> There is no harm in forbidding data_directory, but similarly we can >>> imagine that people can set some very large values for some

Re: [HACKERS] New pg_lsn type doesn't have hash/btree opclasses

On Sun, May 11, 2014 at 7:39 AM, Andres Freund wrote: > (makes me really wish betas were properly tagged with git as well...) They are tags for betas, here is for example the update of CATVERSION for 9.3: $ git log -p REL9_3_BETA1..REL9_3_0 src/include/catalog/catversion.h | grep commit commit dc3

Re: [HACKERS] New pg_lsn type doesn't have hash/btree opclasses

On 2014-05-11 00:31:09 +0200, Magnus Hagander wrote: > On Sun, May 11, 2014 at 12:27 AM, Andres Freund wrote: > > > On 2014-05-10 19:19:22 -0300, Fabrízio de Royes Mello wrote: > > > On Sat, May 10, 2014 at 6:52 PM, Tom Lane wrote: > > > > > > > > Andres Freund writes: > > > > > I don't even und

Re: [HACKERS] New pg_lsn type doesn't have hash/btree opclasses

On Sat, May 10, 2014 at 7:27 PM, Andres Freund wrote: > > On 2014-05-10 19:19:22 -0300, Fabrízio de Royes Mello wrote: > > On Sat, May 10, 2014 at 6:52 PM, Tom Lane wrote: > > > > > > Andres Freund writes: > > > > I don't even understand why it's questionable whether this should be > > > > fixed

Re: [HACKERS] New pg_lsn type doesn't have hash/btree opclasses

Andres Freund writes: > On 2014-05-10 19:19:22 -0300, Fabrízio de Royes Mello wrote: >> Sorry but I don't understand why it's too late. The 9.4 branch not been >> created yet. > The problem is that once the beta is in progress (starting tomorrow), > the projects tries to avoid changes which requi

Re: [HACKERS] New pg_lsn type doesn't have hash/btree opclasses

On Sun, May 11, 2014 at 12:27 AM, Andres Freund wrote: > On 2014-05-10 19:19:22 -0300, Fabrízio de Royes Mello wrote: > > On Sat, May 10, 2014 at 6:52 PM, Tom Lane wrote: > > > > > > Andres Freund writes: > > > > I don't even understand why it's questionable whether this should be > > > > fixed.

Re: [HACKERS] New pg_lsn type doesn't have hash/btree opclasses

On 2014-05-10 19:19:22 -0300, Fabrízio de Royes Mello wrote: > On Sat, May 10, 2014 at 6:52 PM, Tom Lane wrote: > > > > Andres Freund writes: > > > I don't even understand why it's questionable whether this should be > > > fixed. > > > > Sigh. We have some debate isomorphic to this one every yea

Re: [HACKERS] New pg_lsn type doesn't have hash/btree opclasses

On Sat, May 10, 2014 at 6:52 PM, Tom Lane wrote: > > Andres Freund writes: > > I don't even understand why it's questionable whether this should be > > fixed. > > Sigh. We have some debate isomorphic to this one every year, it seems > like. The argument why it shouldn't be fixed now is: ITS. TO

Re: [HACKERS] min_recovery_apply_delay

=?UTF-8?Q?Fabr=C3=ADzio_de_Royes_Mello?= writes: > On Sat, May 10, 2014 at 5:22 PM, Robert Haas wrote: >> On Fri, May 9, 2014 at 10:44 PM, Fabrízio de Royes Mello >> wrote: Wouldn't a better name be recovery_min_apply_delay? >>> +1 >> Works for me. > Done!! Since there were no objectio

Re: [HACKERS] default opclass for jsonb (was Re: Call for GIST/GIN/SP-GIST opclass documentation)

Andrew Dunstan writes: > On 05/10/2014 04:42 PM, Heikki Linnakangas wrote: >> Whether the opclasses use hashing to shorten the key is an orthogonal >> property, and IMHO not as important. To reflect that, I suggest that >> we name the opclasses: >> >> json_path_ops >> json_value_ops >> >> or s

Re: [HACKERS] min_recovery_apply_delay

On Sat, May 10, 2014 at 5:22 PM, Robert Haas wrote: > > On Fri, May 9, 2014 at 10:44 PM, Fabrízio de Royes Mello > wrote: > >> Wouldn't a better name be recovery_min_apply_delay? > > > > +1 > > Works for me. > Done!! -- Fabrízio de Royes Mello Consultoria/Coaching PostgreSQL >> Timbira: http://

Re: [HACKERS] default opclass for jsonb (was Re: Call for GIST/GIN/SP-GIST opclass documentation)

On Sat, May 10, 2014 at 1:42 PM, Heikki Linnakangas wrote: > For example, if you have an object like '{"foo": {"bar": 123 } }', one will > index "foo", "foo->bar", and "foo->bar->123" while the other will index > "foo", "bar" and "123". That isn't quite right, if we're talking about the user's pe

Re: [HACKERS] New pg_lsn type doesn't have hash/btree opclasses

Andres Freund writes: > I don't even understand why it's questionable whether this should be > fixed. Sigh. We have some debate isomorphic to this one every year, it seems like. The argument why it shouldn't be fixed now is: ITS. TOO. LATE. Which part of that isn't clear to you? Or, if you thi

Re: [HACKERS] New pg_lsn type doesn't have hash/btree opclasses

On 2014-05-11 06:02:23 +0900, Fujii Masao wrote: > On Sat, May 10, 2014 at 9:51 AM, Fabrízio de Royes Mello > wrote: > > > > On Fri, May 9, 2014 at 9:30 PM, Tom Lane wrote: > >> [ shrug... ] "proactive" would have been doing this a month ago. > >> If we're going to ship a release, we have to sto

Re: [HACKERS] default opclass for jsonb (was Re: Call for GIST/GIN/SP-GIST opclass documentation)

+1 but bit confused with json instead of jsonb On Sun, May 11, 2014 at 1:00 AM, Andrew Dunstan wrote: > > On 05/10/2014 04:42 PM, Heikki Linnakangas wrote: >> >> >> >> The main difference between the two opclasses from a user's standpoint is >> not whether they hash or not. The big difference is

Re: [HACKERS] New pg_lsn type doesn't have hash/btree opclasses

On Sat, May 10, 2014 at 9:51 AM, Fabrízio de Royes Mello wrote: > > On Fri, May 9, 2014 at 9:30 PM, Tom Lane wrote: >> >> =?UTF-8?Q?Fabr=C3=ADzio_de_Royes_Mello?= writes: >> > On Fri, May 9, 2014 at 8:42 PM, Tom Lane wrote: >> >> I think it's really too late for this for 9.4. At this point it'

Re: [HACKERS] default opclass for jsonb (was Re: Call for GIST/GIN/SP-GIST opclass documentation)

On 05/10/2014 04:42 PM, Heikki Linnakangas wrote: The main difference between the two opclasses from a user's standpoint is not whether they hash or not. The big difference is that one indexes complete paths from the root, and the other indexes just the "leaf" level. For example, if you hav

Re: [HACKERS] Lossy bitmap scan is broken in GIN

On 05/10/2014 10:41 PM, Alexander Korotkov wrote: Hackers, GIN hangs on lossy bitmap scan. Here is test case: create extension btree_gin; create table test as (select random() v from generate_series(1,100)); create index test_idx on test using gin(v); set work_mem = '16MB'; select count(*)

Re: [HACKERS] default opclass for jsonb (was Re: Call for GIST/GIN/SP-GIST opclass documentation)

On 05/09/2014 11:44 PM, Tom Lane wrote: Greg Stark writes: Well the question seems to me to be that if we're always doing recheck then what advantage is there to not hashing everything? Right now, there's not much. But it seems likely to me that there will be more JSON operators in future, a

Re: [HACKERS] Compression of full-page-writes

On Sat, May 10, 2014 at 8:33 PM, Sameer Thakur wrote: > Hello, >>Done. Attached is the updated version of the patch. > I was trying to check WAL reduction using this patch on latest available git > version of Postgres using JDBC runner with tpcc benchmark. > > patching_problems.txt >

Re: [HACKERS] min_recovery_apply_delay

On Fri, May 9, 2014 at 10:44 PM, Fabrízio de Royes Mello wrote: >> Wouldn't a better name be recovery_min_apply_delay? > > +1 Works for me. -- Robert Haas EnterpriseDB: http://www.enterprisedb.com The Enterprise PostgreSQL Company -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgre

Re: [HACKERS] Weird behaviour with the new MOVE clause of ALTER TABLESPACE

* Guillaume Lelarge (guilla...@lelarge.info) wrote: > Thanks for the explanation. I should have RTFM before complaining. Sorry > for the noise :) No prob. If people don't feel that makes sense then we can still change it.. I don't feel particularly strongly either way, though I seem to recall my

Re: [HACKERS] [v9.5] Custom Plan API

* Simon Riggs (si...@2ndquadrant.com) wrote: > What I have said is that authors of CustomJoins or CustomScans should > declare in advance via system catalogs which operators their new code > works with so that Postgres knows when it is appropriate to call them. I guess I just took that as given, s

[HACKERS] Lossy bitmap scan is broken in GIN

Hackers, GIN hangs on lossy bitmap scan. Here is test case: create extension btree_gin; create table test as (select random() v from generate_series(1,100)); create index test_idx on test using gin(v); set work_mem = '16MB'; select count(*) from test where v > 0.9; count ─── 99916 (1 ro

Re: [HACKERS] Sending out a request for more buildfarm animals?

On 9.5.2014 00:47, Tomas Vondra wrote: > On 8.5.2014 23:48, Andrew Dunstan wrote: >> >> On 05/08/2014 05:21 PM, Alvaro Herrera wrote: >>> Andrew Dunstan wrote: >>> I really don't get what your objection to the setup is. And no, I don't want them to run concurrently, I'd rather spread out

Re: [HACKERS] Updating config.guess/config.sub for ppc64le

Re: Tom Lane 2014-05-10 <27476.1399729...@sss.pgh.pa.us> > Christoph Berg writes: > > to support ppc64le, config.guess needs to be updated. The attached > > patch is what was reported to work for Ubuntu. > > Our normal procedure is > > o update config.guess and config.sub at the start of b

Re: [HACKERS] Supporting tcl 8.6

Re: Tom Lane 2014-05-10 <27409.1399729...@sss.pgh.pa.us> > Christoph Berg writes: > > the current tcl version is 8.6, and configure should recognize it. The > > attached patch has been in the Debian/Ubuntu packages for a while, so > > it's tested. > > While that patch looks harmless enough, I'm c

Re: [HACKERS] A couple logical decoding fixes/patches

On 2014-05-10 00:59:59 -0400, Noah Misch wrote: > On Fri, May 09, 2014 at 04:58:54PM +0200, Andres Freund wrote: > > On 2014-05-09 10:49:09 -0400, Robert Haas wrote: > > > > Patch 03: Add valgrind suppression for writing out padding bytes. That's > > > > better than zeroing the data from the get go

Re: [HACKERS] Weird behaviour with the new MOVE clause of ALTER TABLESPACE

On Fri, 2014-05-09 at 17:16 -0400, Stephen Frost wrote: > Guillaume, > > * Guillaume Lelarge (guilla...@lelarge.info) wrote: > > Should information_schema tables be moved and not pg_catalog ones? it > > doesn't seem consistent to me. > > The catalog tables are moved by changing the database's tab

Re: [HACKERS] [bug fix] pg_ctl always uses the same event source

From: "Amit Kapila" I think it's bit late for this patch for 9.4, you might want to move it to next CF. Thanks, I've moved it. It's a regret that this very small patch wasn't put in 9.4. Regards MauMau -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes

Re: [HACKERS] Compression of full-page-writes

Sameer Thakur writes: > I was trying to check WAL reduction using this patch on latest available git > version of Postgres using JDBC runner with tpcc benchmark. > patching_problems.txt > > > I did resolve the patchin

Re: [HACKERS] Updating config.guess/config.sub for ppc64le

Christoph Berg writes: > to support ppc64le, config.guess needs to be updated. The attached > patch is what was reported to work for Ubuntu. Our normal procedure is o update config.guess and config.sub at the start of beta (from http://savannah.gnu.org/projects/config) (memo t

Re: [HACKERS] Supporting tcl 8.6

Christoph Berg writes: > the current tcl version is 8.6, and configure should recognize it. The > attached patch has been in the Debian/Ubuntu packages for a while, so > it's tested. While that patch looks harmless enough, I'm curious why you'd need it --- isn't tcl installed as plain "tclsh"?

Re: [HACKERS] New pg_lsn type doesn't have hash/btree opclasses

On Sat, May 10, 2014 at 2:43 AM, Michael Paquier wrote: > On Fri, May 9, 2014 at 10:49 PM, Fujii Masao > wrote: > > On Fri, May 9, 2014 at 10:03 PM, Andres Freund > wrote: > >> You plan to commit it? > > > > Yes unless many people object the commit. > > > > Michael, you're now modifying the patc

Re: [HACKERS] Compression of full-page-writes

Hello, >Done. Attached is the updated version of the patch. I was trying to check WAL reduction using this patch on latest available git version of Postgres using JDBC runner with tpcc benchmark. patching_problems.txt

Re: [HACKERS] [v9.5] Custom Plan API

On 9 May 2014 02:40, Stephen Frost wrote: > * Simon Riggs (si...@2ndquadrant.com) wrote: >> On 8 May 2014 20:40, Robert Haas wrote: >> > For my money, we'd be better off >> > getting some kind of basic custom scan node functionality committed >> > first, even if the cases where you can actually i

[HACKERS] Updating config.guess/config.sub for ppc64le

Hi, to support ppc64le, config.guess needs to be updated. The attached patch is what was reported to work for Ubuntu. Christoph -- c...@df7cb.de | http://www.df7cb.de/ diff --git a/config/config.guess b/config/config.guess new file mode 100755 index 2055429..b79252d *** a/config/config.guess ---

[HACKERS] Supporting tcl 8.6

Hi, the current tcl version is 8.6, and configure should recognize it. The attached patch has been in the Debian/Ubuntu packages for a while, so it's tested. Christoph -- c...@df7cb.de | http://www.df7cb.de/ diff --git a/config/tcl.m4 b/config/tcl.m4 new file mode 100644 index e886057..a9fe7ba *