Re: [HACKERS] pg_system_identifier()

2013-08-25 Thread Michael Paquier
On Mon, Aug 26, 2013 at 7:47 AM, Jim Nasby wrote: > On 8/23/13 11:23 AM, Greg Stark wrote: >> >> This doesn't generate a unique id. You could back up a standby and restore >> it and point it at the original master and end up with two standbies with >> the same id. > > > If you want to enforce some

Re: [HACKERS] pg_system_identifier()

2013-08-25 Thread Jim Nasby
On 8/23/13 11:23 AM, Greg Stark wrote: This doesn't generate a unique id. You could back up a standby and restore it and point it at the original master and end up with two standbies with the same id. If you want to enforce something unique throughout a cluster, I think we're stuck with havi

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

2013-08-25 Thread Sawada Masahiko
On Sat, Aug 24, 2013 at 11:38 PM, Peter Eisentraut wrote: > On Thu, 2013-07-11 at 23:42 +0900, Sawada Masahiko wrote: >> please find the attached patch. > > Please fix these compiler warnings: > > xlog.c:3117:2: warning: implicit declaration of function ‘SyncRepWaitForLSN’ > [-Wimplicit-function-

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

2013-08-25 Thread Tom Lane
Michael Paquier writes: > On Thu, Aug 22, 2013 at 11:55 PM, Blake Smith wrote: >> The combined entry is used to support "contains (@>)" queries, and the key >> only item is used to support "key contains (?)" queries. This change seems >> to help especially with hstore keys that have high cardinal

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

2013-08-25 Thread Michael Paquier
On Thu, Aug 22, 2013 at 11:55 PM, Blake Smith wrote: > We've been experiencing slow "@>" queries involving an hstore column that's > covered by a Gin index. At the current postgresql git HEAD, the hstore <-> > gin interface produces the following text items to be indexed: > > hstore: "'a'=>'1234',

Re: [HACKERS] Performance problem in PLPgSQL

2013-08-25 Thread Pavel Stehule
2013/8/23 Tom Lane > Pavel Stehule writes: > > please, can you send a self explained test > > this issue should be fixed, and we need a examples. > > We already had a perfectly good example at the beginning of this thread. > What's missing is a decision on how we ought to approximate the cost of

Re: [HACKERS] Unpacking scalar JSON values

2013-08-25 Thread Josh Berkus
> > This came up recently on -bugs. See > , > where I suggested we expose the dequoting function. +1. As it is, I use btrim() heaviy with JSON data. -- Josh Berkus PostgreSQL Experts Inc. http://pgexperts.com -- Sent via

Re: [HACKERS] proposal: lob conversion functionality

2013-08-25 Thread Pavel Stehule
2013/8/25 Pavel Stehule > Hello > > here is a patch > > it introduce a load_lo and make_lo functions > > postgres=# select make_lo(decode('ff00','hex')); > make_lo > ─ >24629 > (1 row) > > Time: 40.724 ms > postgres=# select load_lo(24628); > load_lo > > \xff0

Re: [HACKERS] proposal: lob conversion functionality

2013-08-25 Thread Pavel Stehule
Hello here is a patch it introduce a load_lo and make_lo functions postgres=# select make_lo(decode('ff00','hex')); make_lo ─ 24629 (1 row) Time: 40.724 ms postgres=# select load_lo(24628); load_lo \xff00 (1 row) postgres=# \lo_import ~/avatar.png lo_import

Re: [HACKERS] Unpacking scalar JSON values

2013-08-25 Thread Andrew Dunstan
On 08/24/2013 09:08 PM, Daniel Farina wrote: On Sat, Aug 24, 2013 at 6:04 PM, Daniel Farina wrote: But there's no good way I can find from the documentation to do it with a scalar: select ('"va\"lue"'::json)::text; Triggered send by accident: select ('"va\"lue"'::json)::text; text --

Re: [HACKERS] Performance problem in PLPgSQL

2013-08-25 Thread Marc Cousin
On 24/08/2013 21:16, Tom Lane wrote: Marc Cousin writes: On 23/08/2013 23:55, Tom Lane wrote: My previous suggestion was to estimate planning cost as 10 * (length(plan->rangetable) + 1) but on reflection it ought to be scaled by one of the cpu cost constants, so perhaps 1000 * cpu_operator_cos