Re: [HACKERS] Cluster name in ps output

On Wed, Jul 2, 2014 at 3:45 AM, Vik Fearing wrote: > On 06/29/2014 02:25 PM, Andres Freund wrote: >> On 2014-06-29 11:11:14 +0100, Thomas Munro wrote: >>> > On 29 June 2014 10:55, Andres Freund wrote: > > So, I'd looked at it with an eye towards committing it and found some > > more thi

Re: [HACKERS] pg_xlogdump --stats

At 2014-06-30 05:19:10 +, dilip.ku...@huawei.com wrote: > > Please fix these issues and send the updated patch.. > > I will continue reviewing the patch.. Did you get anywhere with the updated patch? -- Abhijit -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make

Re: [HACKERS] Can simplify 'limit 1' with slow function?

Fascinating. On Fri, Jul 04, 2014 at 10:47:06AM +0800, gotoschool6g wrote: > slow query(8531 ms): > SELECT ST_Distance_Sphere(shape,ST_GeomFromText('POINT(116.41386186784513 > 40.12211338311868)')) FROM road order by id LIMIT 1; > > explain output: > "Limit (cost=4653.48..4653.48 rows=1 width=3

Re: [HACKERS] Issue while calling new PostgreSQL command from a Java Application

You may have to add code to copy inp_str to _copyVacuumStmt(). See how a character array being copied from other _copy* functions. On Fri, Jul 4, 2014 at 10:43 AM, Ashoke wrote: > Hi, > > -- > > I have defined a new command my_command in PostgreSQL. This command take

Re: [HACKERS] Issue while calling new PostgreSQL command from a Java Application

At 2014-07-04 10:43:12 +0530, s.ash...@gmail.com wrote: > > I am not sure how executing the same command from an application can > make a difference. It shouldn't make any difference, of course. But since you're seeing the problem with new code, the overwhelming probability is that there's an err

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

At 2014-07-04 14:38:27 +0900, masao.fu...@gmail.com wrote: > > But 0002-CompressBackupBlock_snappy_lz4_pglz-2.patch doesn't seem to > be able to apply to HEAD cleanly. Yes, and it needs quite some reformatting beyond fixing whitespace damage too (long lines, comment formatting, consistent spacing

Re: [HACKERS] RLS Design

Sorry for my late responding, now I'm catching up the discussion. > * Robert Haas (robertmh...@gmail.com) wrote: > > On Tue, Jul 1, 2014 at 3:20 PM, Dean Rasheed > wrote: > > > If RLS quals are instead regarded as constraints on access, and > > > multiple policies apply, then it seems that the qu

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

On Fri, Jul 4, 2014 at 4:58 AM, Rahila Syed wrote: > Hello, > > Updated version of patches are attached. > Changes are as follows > 1. Improved readability of the code as per the review comments. > 2. Addition of block_compression field in BkpBlock structure to store > information about compressio

[HACKERS] Issue while calling new PostgreSQL command from a Java Application

Hi, -- I have defined a new command my_command in PostgreSQL. This command takes the path of ANALYZE and inside analyze.c, I have a function to do some operations if its my_command.This command takes the input arguments: table name, column name and an input string. my

Re: [HACKERS] "RETURNING PRIMARY KEY" syntax extension

On Fri, Jul 4, 2014 at 7:37 AM, Tom Lane wrote: > Tom Dunstan writes: > > On 4 July 2014 00:07, Tom Lane wrote: > >> It sounds to me like designing this for JDBC's getGeneratedKeys method > >> is a mistake. There isn't going to be any way that the driver can > support > >> that without having

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

Hanada-san, Thanks for your dedicated reviewing. It's a very long message. So, let me summarize the things I shall do in the next patch. * fix bug: custom-plan class comparison * fix up naming convention and syntax CREATE CUSTOM PLAN PROVIDER, rather than CREATE CUSTOM PLAN. Prefix shall be

Re: [HACKERS] Pg_upgrade and toast tables bug discovered

On Thu, Jul 3, 2014 at 11:55:40PM +0200, Andres Freund wrote: > I don't think it's just that simple unfortunately. If pg_class entries > get created that didn't exist on the old server there's a chance for oid > conflicts. Consider > > SELECT binary_upgrade.set_next_heap_pg_class_oid('17094'::pg_

Re: [HACKERS] Pg_upgrade and toast tables bug discovered

On Thu, Jul 3, 2014 at 05:09:41PM -0400, Tom Lane wrote: > Bruce Momjian writes: > > I have had trouble getting a table schema that is causing problems, but > > received a report via EDB support recently that had a simple schema > > (anonymized): > > ... > > needs_toast_table() computes the lengt

Re: [HACKERS] pg_receivexlog add synchronous mode

On Tue, Jul 1, 2014 at 10:11 PM, Fujii Masao wrote: > On Mon, Jun 30, 2014 at 7:09 PM, wrote: >>> Thanks for the review! >>> >>> +if (secs <= 0) >>> +secs = 1;/* Always sleep at least 1 sec */ >>> + >>> +sleeptime = secs * 1000 + usecs / 1000; >>> >>>

Re: [HACKERS] Can simplify 'limit 1' with slow function?

slow query(8531 ms): SELECT ST_Distance_Sphere(shape,ST_GeomFromText('POINT(116.41386186784513 40.12211338311868)')) FROM road order by id LIMIT 1; explain output: "Limit (cost=4653.48..4653.48 rows=1 width=3612)" " -> Sort (cost=4653.48..4683.06 rows=11832 width=3612)" "Sort Key: id"

Re: [HACKERS] docs: additional subsection for page-level locks in explicit-locking section

On Fri, Jul 4, 2014 at 12:51 AM, Kevin Grittner wrote: > Fujii Masao wrote: > >> This seems to make sense. Barring objection, I will commit this >> only in HEAD. Committed. > I'm inclined to think this is a slight improvement, just for the > sake of consistency with peer level information. You

Re: [HACKERS] "RETURNING PRIMARY KEY" syntax extension

On 4 July 2014 11:37, Tom Lane wrote: > > > Sure it can - it append RETURNING PRIMARY KEY and hand back a ResultSet > > from whatever was returned. It's CURRENTLY doing that, but it's appending > > RETURNING * and leaving it up to the caller of getGeneratedKeys() to work > > out which columns the

Re: [HACKERS] "RETURNING PRIMARY KEY" syntax extension

Tom Dunstan writes: > On 4 July 2014 00:07, Tom Lane wrote: >> It sounds to me like designing this for JDBC's getGeneratedKeys method >> is a mistake. There isn't going to be any way that the driver can support >> that without having looked at the table's metadata for itself, and if >> it's goin

Re: [HACKERS] "RETURNING PRIMARY KEY" syntax extension

On 4 July 2014 00:07, Tom Lane wrote: > TBH, I thought that RETURNING PRIMARY KEY was already fairly iffy > in that the application would have little idea what it was getting back. > IF EXISTS would make it so spongy as to be useless, IMO. > IF EXISTS is pretty pointless - while the behaviour of

Re: [HACKERS] Aggregate function API versus grouping sets

Andrew Gierth writes: > Here are two more, cumulative with the previous patch and each other: > The first removes the assumption in ordered_set_startup that the > aggcontext can be cached in fn_extra, and puts it in the transvalue > instead. OK, done. (ATM it seems like we wouldn't need gcontext

Re: [HACKERS] Aggregate function API versus grouping sets

> "Tom" == Tom Lane writes: >> How's this? (applies and passes regression on 9.4 and master) Tom> Pushed with minor cosmetic adjustments. Thanks! -- Andrew (irc:RhodiumToad) -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: h

Re: [HACKERS] Aggregate function API versus grouping sets

Andrew Gierth writes: > "Tom" == Tom Lane writes: > Tom> If we're going to do that, I think it needs to be in 9.4. Are > Tom> you going to work up a patch? > How's this? (applies and passes regression on 9.4 and master) Pushed with minor cosmetic adjustments. regard

Re: [HACKERS] Pg_upgrade and toast tables bug discovered

On 2014-07-03 17:09:41 -0400, Tom Lane wrote: > Bruce Momjian writes: > > I have had trouble getting a table schema that is causing problems, but > > received a report via EDB support recently that had a simple schema > > (anonymized): > > ... > > needs_toast_table() computes the length of this ta

Re: [HACKERS] tweaking NTUP_PER_BUCKET

On 3.7.2014 20:50, Tomas Vondra wrote: > Hi Stephen, > > On 3.7.2014 20:10, Stephen Frost wrote: >> Tomas, >> >> * Tomas Vondra (t...@fuzzy.cz) wrote: >>> However it's likely there are queries where this may not be the case, >>> i.e. where rebuilding the hash table is not worth it. Let me know if

Re: [HACKERS] Pg_upgrade and toast tables bug discovered

Bruce Momjian writes: > I have had trouble getting a table schema that is causing problems, but > received a report via EDB support recently that had a simple schema > (anonymized): > ... > needs_toast_table() computes the length of this table as 2024 bytes in > 9.0, and 2064 bytes on 9.1, with th

Re: [HACKERS] "RETURNING PRIMARY KEY" syntax extension

Greg Stark writes: > On Thu, Jul 3, 2014 at 7:37 AM, Tom Lane wrote: >> TBH, I thought that RETURNING PRIMARY KEY was already fairly iffy >> in that the application would have little idea what it was getting back. >> IF EXISTS would make it so spongy as to be useless, IMO. > Seems easy enough to

Re: [HACKERS] Array of composite types returned from python

I wrote: > Ronan Dunklau writes: >> I don't know how to do that without implementing the cache itself. > I don't either, but my thought was that we could hack up a simple > one-element cache pretty trivially, eg static info and desc variables > in PLyObject_ToComposite that are initialized the fi

Re: [HACKERS] Aggregate function API versus grouping sets

Here are two more, cumulative with the previous patch and each other: The first removes the assumption in ordered_set_startup that the aggcontext can be cached in fn_extra, and puts it in the transvalue instead. The second exposes the OSA* structures in a header file, so that user-defined ordered

[HACKERS] Pg_upgrade and toast tables bug discovered

There have been periodic reports of pg_upgrade errors related to toast tables. The most recent one was from May of this year: http://www.postgresql.org/message-id/flat/20140520202223.gb3...@momjian.us#20140520202223.gb3...@momjian.us There error was: Copying user relation files

Re: [HACKERS] Aggregate function API versus grouping sets

> "Tom" == Tom Lane writes: Tom> If we're going to do that, I think it needs to be in 9.4. Are Tom> you going to work up a patch? How's this? (applies and passes regression on 9.4 and master) -- Andrew (irc:RhodiumToad) diff --git a/src/backend/executor/nodeAgg.c b/src/backend/executo

Re: [HACKERS] "RETURNING PRIMARY KEY" syntax extension

On Thu, Jul 3, 2014 at 7:37 AM, Tom Lane wrote: > TBH, I thought that RETURNING PRIMARY KEY was already fairly iffy > in that the application would have little idea what it was getting back. > IF EXISTS would make it so spongy as to be useless, IMO. Seems easy enough to look at the count of colum

Re: [HACKERS] tweaking NTUP_PER_BUCKET

On Thu, Jul 3, 2014 at 11:40 AM, Atri Sharma wrote: > IIRC, last time when we tried doing bloom filters, I was short of some real > world useful hash functions that we could use for building the bloom filter. Last time was we wanted to use bloom filters in hash joins to filter out tuples that won

Re: [HACKERS] tweaking NTUP_PER_BUCKET

Hi Stephen, On 3.7.2014 20:10, Stephen Frost wrote: > Tomas, > > * Tomas Vondra (t...@fuzzy.cz) wrote: >> However it's likely there are queries where this may not be the case, >> i.e. where rebuilding the hash table is not worth it. Let me know if you >> can construct such query (I wasn't). > >

Re: [HACKERS] tweaking NTUP_PER_BUCKET

On Thu, Jul 3, 2014 at 11:40 PM, Stephen Frost wrote: > Tomas, > > * Tomas Vondra (t...@fuzzy.cz) wrote: > > However it's likely there are queries where this may not be the case, > > i.e. where rebuilding the hash table is not worth it. Let me know if you > > can construct such query (I wasn't).

Re: [HACKERS] bad estimation together with large work_mem generates terrible slow hash joins

On 3.7.2014 15:42, Atri Sharma wrote: > > > > On Tue, Jul 1, 2014 at 4:54 AM, Tomas Vondra > wrote: > > On 30.6.2014 23:12, Tomas Vondra wrote: > > Hi, > > > > attached is v5 of the patch. The main change is that scaling the > number > > of buckets

Re: [HACKERS] tweaking NTUP_PER_BUCKET

Tomas, * Tomas Vondra (t...@fuzzy.cz) wrote: > However it's likely there are queries where this may not be the case, > i.e. where rebuilding the hash table is not worth it. Let me know if you > can construct such query (I wasn't). Thanks for working on this! I've been thinking on this for a whil

Re: [HACKERS] tweaking NTUP_PER_BUCKET

On 3.7.2014 02:13, Tomas Vondra wrote: > Hi, > > while hacking on the 'dynamic nbucket' patch, scheduled for the next CF > (https://commitfest.postgresql.org/action/patch_view?id=1494) I was > repeatedly stumbling over NTUP_PER_BUCKET. I'd like to propose a change > in how we handle it. > > > TL

Re: [HACKERS] bad estimation together with large work_mem generates terrible slow hash joins

On 1.7.2014 01:24, Tomas Vondra wrote: > On 30.6.2014 23:12, Tomas Vondra wrote: >> Hi, > > Hopefully I got it right this time. At least it seems to be working for > cases that failed before (no file leaks, proper rowcounts so far). Attached v7, fixing nbatch/ntuples in an assert. regards Tomas d

Re: [HACKERS] Setting PG-version without recompiling

På torsdag 03. juli 2014 kl. 16:16:01, skrev Tom Lane mailto:t...@sss.pgh.pa.us>>: Andreas Joseph Krogh writes: > Hi. �� I'm up for testing 9.4 but my JDBC-driver fails to connect due to PG's > minor-version string: "4beta1". Is it possible to set this somewhere without > recompiling PG? No,

Re: [HACKERS] docs: additional subsection for page-level locks in explicit-locking section

Fujii Masao wrote: > This seems to make sense. Barring objection, I will commit this > only in HEAD. I'm inclined to think this is a slight improvement, just for the sake of consistency with peer level information.  You probably already noticed, but the patch as submitted neglects to close the p

Re: [HACKERS] "RETURNING PRIMARY KEY" syntax extension

Rushabh Lathia writes: > On Thu, Jul 3, 2014 at 6:56 AM, Ian Barwick wrote: >> A better solution would be to have an optional "IF EXISTS" clause: >> RETURNING PRIMARY KEY [ IF EXISTS ] > Hmm liked the idea about adding [ IF EXISTS ]. Looking at the grammar so > far we > having [ IF EXISTS ] opti

Re: [HACKERS] Setting PG-version without recompiling

Andreas Joseph Krogh writes: > Hi.   I'm up for testing 9.4 but my JDBC-driver fails to connect due to PG's > minor-version string: "4beta1". Is it possible to set this somewhere without > recompiling PG? No, and even if you could, that would be the wrong approach. The right approach is to fi

Re: [HACKERS] Proposing pg_hibernate

Amit Kapila wrote: > Overall I agree that following Robert's idea will increase the > time to make database server up and reach a state where apps can > connect and start operations, I agree that warming the cache before beginning to apply WAL would be best. > but I think atleast with such an a

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

Kaigai-san, Sorry for lagged response. Here are my random thoughts about the patch. I couldn't understand the patch fully, because some of APIs are not used by ctidscan. If Custom Scan patch v2 review * Custom plan class comparison In backend/optimizer/util/pathnode.c, custclass is compared

Re: [HACKERS] bad estimation together with large work_mem generates terrible slow hash joins

On Tue, Jul 1, 2014 at 4:54 AM, Tomas Vondra wrote: > On 30.6.2014 23:12, Tomas Vondra wrote: > > Hi, > > > > attached is v5 of the patch. The main change is that scaling the number > > of buckets is done only once, after the initial hash table is build. The > > main advantage of this is lower pr

Re: [HACKERS] docs: additional subsection for page-level locks in explicit-locking section

On Thu, Jul 3, 2014 at 4:34 AM, Michael Banck wrote: > Hi, > > While reading through the Explicit Locking section of the manual today, > I felt the last paragraph of section 13.3.2. (Row-level Locks) might > merit its own subsection. It talks about page-level locks as distinct > from table- and r

Re: [HACKERS] Should extension--unpackaged-$ver.sql's \echo use FROM unpackaged;?

On Thu, Jul 3, 2014 at 4:26 AM, Andres Freund wrote: > Hi, > > Fujii noticed that I'd used > \echo Use "CREATE EXTENSION pg_buffercache" to load this file. \quit > in an extension upgrade script. That's obviously wrong, because it > should say ALTER EXTENSION. The reason it's that way is that I co

Re: [HACKERS] gaussian distribution pgbench

On 2014-07-03 21:27:53 +0900, Fujii Masao wrote: > > Add drawing random integers with a Gaussian or truncated exponentional > > distributions to pgbench. > > > > Test variants with these distributions are also provided and triggered > > with options "--gaussian=..." and "--exponential=...". > > II

Re: [HACKERS] gaussian distribution pgbench

On Wed, Jul 2, 2014 at 6:05 PM, Fabien COELHO wrote: > > Hello Mitsumasa-san, > >> And I'm also interested in your "decile percents" output like under >> followings, >> decile percents: 39.6% 24.0% 14.6% 8.8% 5.4% 3.3% 2.0% 1.2% 0.7% 0.4% > > > Sure, I'm really fine with that. > > >> I think that

Re: [HACKERS] [PATCH] introduce XLogLockBlockRangeForCleanup()

On 3 July 2014 06:45, Amit Khandekar wrote: > In GetBufferWithoutRelcache(), I was wondering, rather than calling > PinBuffer(), if we do this : > LockBufHdr(buf); > PinBuffer_Locked(buf); > valid = ((buf->flags & BM_VALID) != 0); > then we can avoid having the new buffer access strategy BAS_DISC

Re: [HACKERS] [PATCH] introduce XLogLockBlockRangeForCleanup()

FYI, I've attached a patch that does what you suggested. I haven't done anything else (i.e. testing) with it yet. -- Abhijit diff --git a/src/backend/access/nbtree/nbtxlog.c b/src/backend/access/nbtree/nbtxlog.c index 5f9fc49..dc90c02 100644 --- a/src/backend/access/nbtree/nbtxlog.c +++ b/src/back

Re: [HACKERS] WAL replay bugs

Hello, This is the additional comments for other part. I haven't see significant defect in the code so far. = bufcapt.c: - buffer_capture_remember() or so. Pages for unlogged tables are avoided to be written taking advantage that the lsn for such pages stays 0/0. I'd like to see a comm

Re: [HACKERS] Perfomance degradation 9.3 (vs 9.2) for FreeBSD

Hi, > Hi, > > Attached you can find a short (compile tested only ) patch implementing > a 'shared_memory_type' GUC, akin to 'dynamic_shared_memory_type'. Will > only apply to 9.4, not 9.3, but it should be easy to convert for it. > > Greetings, > > Andres Freund I have rebased Andres's patch a

Re: [HACKERS] gaussian distribution pgbench

On 03/07/14 20:58, Fabien COELHO wrote: Hello Gavin, decile percents: 69.9% 21.0% 6.3% 1.9% 0.6% 0.2% 0.1% 0.0% 0.0% 0.0% probability of fist/last percent of the range: 11.3% 0.0% I would suggest that probabilities should NEVER be expressed in percentages! As a percentage probability look

Re: [HACKERS] Setting PG-version without recompiling

På torsdag 03. juli 2014 kl. 11:13:44, skrev Abhijit Menon-Sen < a...@2ndquadrant.com >: At 2014-07-03 11:02:34 +0200, andr...@visena.com wrote: > > Is it possible to set this somewhere without > recompiling PG? I'm afraid not.   Ok   -- Andreas Jospeh Krogh CTO /

Re: [HACKERS] Setting PG-version without recompiling

At 2014-07-03 11:02:34 +0200, andr...@visena.com wrote: > > Is it possible to set this somewhere without > recompiling PG? I'm afraid not. -- Abhijit -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/

Re: [HACKERS] "RETURNING PRIMARY KEY" syntax extension

On Thu, Jul 3, 2014 at 6:56 AM, Ian Barwick wrote: > On 01/07/14 21:00, Rushabh Lathia wrote: > >> >> I spent some more time on the patch and here are my review comments. >> >> .) Patch gets applied through patch -p1 (git apply fails) >> >> .) trailing whitespace in the patch at various places >>

[HACKERS] Setting PG-version without recompiling

Hi.   I'm up for testing 9.4 but my JDBC-driver fails to connect due to PG's minor-version string: "4beta1". Is it possible to set this somewhere without recompiling PG?   Thanks.   -- Andreas Jospeh Krogh CTO / Partner - Visena AS Mobile: +47 909 56 963 andr...@visena.com

Re: [HACKERS] gaussian distribution pgbench

Hello Gavin, decile percents: 69.9% 21.0% 6.3% 1.9% 0.6% 0.2% 0.1% 0.0% 0.0% 0.0% probability of fist/last percent of the range: 11.3% 0.0% I would suggest that probabilities should NEVER be expressed in percentages! As a percentage probability looks weird, and is never used for serious s

Re: [HACKERS] Autonomous Transaction (WIP)

On Thu, Jul 3, 2014 at 12:03 PM, Rajeev rastogi wrote: > On 01 July 2014 12:00, Amit Kapila Wrote: > >Simon has mentioned that exactly this idea has been rejected at > > >PGCon 2 years back. Please refer that in below mail: > > > http://www.postgresql.org/message-id/bf2827dcce55594c8d7a8f7ffd3ab77