Re: [HACKERS] Performance problem in PLPgSQL

2013-07-23 Thread Amit Kapila
On Wednesday, July 24, 2013 4:23 AM Tom Lane wrote: > I wrote: > > Marc Cousin writes: > >> The example below is of course extremely simplified, and obviously > not > >> what we are really doing in the database, but it exhibits the > slowdown > >> between 9.1.9 and 9.2.4. > > > Hm. Some experime

Re: [HACKERS] maintenance_work_mem and CREATE INDEX time

2013-07-23 Thread Amit Langote
On Wed, Jul 24, 2013 at 3:20 AM, Jeff Janes wrote: > On Mon, Jul 22, 2013 at 9:11 PM, Amit Langote wrote: >> Hello, >> >> While understanding the effect of maintenance_work_mem on time taken >> by CREATE INDEX, I observed that for the values of >> maintenance_work_mem less than the value for whic

Re: ALTER SYSTEM SET command to change postgresql.conf parameters (RE: [HACKERS] Proposal for Allow postgresql.conf values to be changed via SQL [review])

2013-07-23 Thread Amit Kapila
On Tuesday, July 23, 2013 5:06 AM Josh Berkus wrote: > All, > > Christophe just discovered something with include files which is going > to cause issues with ALTER SYSTEM SET. > > So, take as a hypothetical that you use the default postgresql.conf > file, which sets shared_buffers = 32MB. > > In

Re: [HACKERS] Proposal/design feedback needed: WITHIN GROUP (sql standard ordered set aggregate functions)

2013-07-23 Thread Andrew Gierth
Noah Misch said: > Other aggregates based on this syntax might not desire such type unification. Then there would have to be some way to distinguish that. Maybe those could have -1 and the standard hypothetical set functions -2, with some flag in CREATE AGGREGATE to sort it out. > Having parse an

Re: [HACKERS] Shorter iterations of join_info_list

2013-07-23 Thread Tom Lane
[ sorry for slow response, this month has been mostly crazy ] Antonin Houska writes: > As far as I understand, deconstruct_recurse() ensures that > SpecialJoinInfo of a new join always gets added to higher position in > join_info_list than SJ infos of all joins located below the new join in >

[HACKERS] Re: Suggestion for concurrent index creation using a single full scan operation

2013-07-23 Thread Noah Misch
On Tue, Jul 23, 2013 at 01:06:26PM +0100, Tim Kane wrote: > I haven't given this a lot of thought, but it struck me that when > rebuilding tables (be it for a restore process, or some other operational > activity) - there is more often than not a need to build an index or two, > sometimes many inde

Re: [HACKERS] maintenance_work_mem and CREATE INDEX time

2013-07-23 Thread Amit Langote
On Wed, Jul 24, 2013 at 11:30 AM, Amit Langote wrote: > On Wed, Jul 24, 2013 at 6:02 AM, Jeff Janes wrote: >> If you are using trace_sort to report that, it reports the switch as >> happening as soon as it runs out of memory. >> >> At point, all we have been doing is reading tuples into memory.

Re: [HACKERS] maintenance_work_mem and CREATE INDEX time

2013-07-23 Thread Amit Langote
On Wed, Jul 24, 2013 at 6:02 AM, Jeff Janes wrote: > On Tue, Jul 23, 2013 at 1:23 AM, Amit Langote wrote: >> On Tue, Jul 23, 2013 at 1:11 PM, Amit Langote >> wrote: >>> Hello, >>> >>> While understanding the effect of maintenance_work_mem on time taken >>> by CREATE INDEX, I observed that for t

[HACKERS] Re: Proposal/design feedback needed: WITHIN GROUP (sql standard ordered set aggregate functions)

2013-07-23 Thread Noah Misch
On Tue, Jul 23, 2013 at 01:21:52AM +, Andrew Gierth wrote: > For hypothetical set functions we add a special case, aggordnargs=-1, > for which both the aggregate and the finalfn must be defined as > (variadic "any") and parse analysis detects this case and unifies the > types of the normal args

Re: [HACKERS] Preventing tuple-table leakage in plpgsql

2013-07-23 Thread Noah Misch
On Mon, Jul 22, 2013 at 10:02:30PM -0400, Tom Lane wrote: > Noah Misch writes: > > On Sun, Jul 21, 2013 at 12:40:38PM -0400, Tom Lane wrote: > >> Hmm ... good point. The other plan I'd been considering was to add > >> explicit tracking inside spi.c of all tuple tables created within the > >> curr

Re: [HACKERS] Review: UNNEST (and other functions) WITH ORDINALITY

2013-07-23 Thread Tom Lane
Stephen Frost writes: > * Andrew Gierth (and...@tao11.riddles.org.uk) wrote: >> If you have legitimate technical concerns then let's hear them, now. > Fine- I'd have been as happy leaving this be and letting Greg commit it, > but if you'd really like to hear my concerns, I'd start with pointing >

Re: [HACKERS] improve Chinese locale performance

2013-07-23 Thread Quan Zongliang
On 07/23/2013 09:42 PM, Craig Ringer wrote: (Replying on phone, please forgive bad quoting) Isn't this pretty much what adopting ICU is supposed to give us? OS-independent collations? Yes, we need OS-independent collations. I'd be interested in seeing the rest data for this performance repo

Re: [HACKERS] Review: UNNEST (and other functions) WITH ORDINALITY

2013-07-23 Thread Andrew Gierth
Stephen Frost said: > [stuff about foreign tables] I think the issue with foreign tables is probably moot because if you _did_ want to have some types of foreign tables with a fixed ordinality, you'd probably also want qual pushdown to work for it (i.e. so that WHERE rownum=123 doesn't have to fil

Re: [HACKERS] Review: UNNEST (and other functions) WITH ORDINALITY

2013-07-23 Thread Stephen Frost
On Tuesday, July 23, 2013, David Fetter wrote: > > Are you saying that there's stuff that if I don't put it in now will > impede our ability to add this to FTs later? > I'm saying that it'd be a completely different implementation and that this one would get in the way and essentially have to be r

[HACKERS] Failure to use generic plans (was: Re: Performance problem in PLPgSQL)

2013-07-23 Thread Andrew Gierth
As failures to use a generic plan goes, that one's fairly tame. I've seen much worse. For example: PREPARE foo(integer[]) AS SELECT * FROM complexview WHERE id = ANY ($1); where the caller typically supplies 1-5 array elements (or any number less than 10, because generic parameter arrays are assu

Re: [HACKERS] Performance problem in PLPgSQL

2013-07-23 Thread Tom Lane
I wrote: > Marc Cousin writes: >> The example below is of course extremely simplified, and obviously not >> what we are really doing in the database, but it exhibits the slowdown >> between 9.1.9 and 9.2.4. > Hm. Some experimentation shows that the plan cache is failing to switch > to a generic

Re: [HACKERS] [v9.4] row level security

2013-07-23 Thread Josh Berkus
On 07/23/2013 03:34 PM, Greg Smith wrote: > I happen to think the review structure is one of the most important > components to PostgreSQL release quality. It used to be a single level > review with just the committers, now it's a two level structure. The > reason the Postgres code is so good is

Re: [HACKERS] [v9.4] row level security

2013-07-23 Thread Greg Smith
On 7/23/13 2:30 PM, Josh Berkus wrote: You know as well as me that, as consultants, we can get clients to pay for 10% extra time for review in the course of developing a feature Before this number gets quoted anywhere, I think it's on the low side. I've spent a good bit of time measuring how

Re: [HACKERS] Review: UNNEST (and other functions) WITH ORDINALITY

2013-07-23 Thread David Fetter
On Tue, Jul 23, 2013 at 06:09:20PM -0400, Stephen Frost wrote: > David > > On Tuesday, July 23, 2013, David Fetter wrote: > > > > There are a lot of ways foreign tables don't yet act like local > > ones. Much as I'm a booster for fixing that problem, I'm thinking > > improvements in this directio

Re: [HACKERS] Review: UNNEST (and other functions) WITH ORDINALITY

2013-07-23 Thread Stephen Frost
David On Tuesday, July 23, 2013, David Fetter wrote: > > There are a lot of ways foreign tables don't yet act like local ones. > Much as I'm a booster for fixing that problem, I'm thinking > improvements in this direction are for a separate patch. > This isn't about making FDWs more like local ta

Re: [HACKERS] Review: UNNEST (and other functions) WITH ORDINALITY

2013-07-23 Thread David Fetter
On Tue, Jul 23, 2013 at 05:23:17PM -0400, Stephen Frost wrote: > * Greg Stark (st...@mit.edu) wrote: > > So given that WITH ORDINALITY is really only useful for UNNEST and we > > can generalize it to all SRFs on the basis that Postgres SRFs do > > produce ordered sets not unordered relations it isn

Re: ALTER SYSTEM SET command to change postgresql.conf parameters (RE: [HACKERS] Proposal for Allow postgresql.conf values to be changed via SQL [review])

2013-07-23 Thread Josh Berkus
> Everything was already *not* hunky-dory as soon as you did that, since > a SIGHUP would have had the same problem. > > I'd be inclined to think that ALTER SYSTEM SET should not be allowed to > modify any PGC_POSTMASTER parameters. That makes alter system set a bunch less useful, but might be i

Re: [HACKERS] Review: UNNEST (and other functions) WITH ORDINALITY

2013-07-23 Thread Stephen Frost
* Greg Stark (st...@mit.edu) wrote: > So given that WITH ORDINALITY is really only useful for UNNEST and we > can generalize it to all SRFs on the basis that Postgres SRFs do > produce ordered sets not unordered relations it isn't crazy for the > work to be in the Function node. I agree, it isn't

Re: [HACKERS] Review: UNNEST (and other functions) WITH ORDINALITY

2013-07-23 Thread Greg Stark
On Tue, Jul 23, 2013 at 9:27 PM, Stephen Frost wrote: > > Fine- I'd have been as happy leaving this be and letting Greg commit it, > but if you'd really like to hear my concerns, I'd start with pointing > out that it's pretty horrid to have to copy every record around like > this and that the hack

Re: [HACKERS] maintenance_work_mem and CREATE INDEX time

2013-07-23 Thread Jeff Janes
On Tue, Jul 23, 2013 at 1:23 AM, Amit Langote wrote: > On Tue, Jul 23, 2013 at 1:11 PM, Amit Langote wrote: >> Hello, >> >> While understanding the effect of maintenance_work_mem on time taken >> by CREATE INDEX, I observed that for the values of >> maintenance_work_mem less than the value for wh

Re: [HACKERS] Review: UNNEST (and other functions) WITH ORDINALITY

2013-07-23 Thread Stephen Frost
Andrew, * Andrew Gierth (and...@tao11.riddles.org.uk) wrote: > Right, and we all know that all code is perfect when committed. sheesh. That clearly wasn't what was claimed. > (This is actually the first time in six months that I've had occasion > to look at that part of the code; that's how long

Re: [HACKERS] Review: UNNEST (and other functions) WITH ORDINALITY

2013-07-23 Thread Andrew Gierth
Tom Lane said: > If you yourself are still finding bugs in the code as of this afternoon, > onlookers could be forgiven for doubting that the code is quite as > readable or ready to commit as all that. Right, and we all know that all code is perfect when committed. sheesh. (This is actually the f

[HACKERS] Adding Zigzag Merge Join to Index Nested Loops Join

2013-07-23 Thread tubadzin
Hi. I want add Zigzag Merge join to Index Nested Loops Join alghoritm. http://www.cs.berkeley.edu/~fox/summaries/database/query_eval_5-8.html Which files are responsible for Index nested loops join ? (not simple nested loops join which has double foreach in nodeNestloop.c) nodeIndexscan.c? nodeI

Re: [HACKERS] getting rid of SnapshotNow

2013-07-23 Thread Tom Lane
Robert Haas writes: > OK, so GetActiveSnapshot()? Works for me. regards, tom lane -- 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] getting rid of SnapshotNow

2013-07-23 Thread Robert Haas
On Tue, Jul 23, 2013 at 2:24 PM, Tom Lane wrote: > Robert Haas writes: >> On Tue, Jul 23, 2013 at 12:28 PM, Tom Lane wrote: >>> As far as get_actual_variable_range() is concerned, an MVCC snapshot >>> would probably be the thing to use anyway; > >> That surprises me, though. I really thought th

Re: [HACKERS] [v9.4] row level security

2013-07-23 Thread Josh Berkus
Greg, > It's more than the available experienced reviewers are willing to chew > on fully as volunteers. The reward for spending review time is pretty > low right now. Short of paying for review time, I don't think we have another solution for getting the "big patches" reviewed, except to rely o

Re: [HACKERS] getting rid of SnapshotNow

2013-07-23 Thread Tom Lane
Robert Haas writes: > On Tue, Jul 23, 2013 at 12:28 PM, Tom Lane wrote: >> As far as get_actual_variable_range() is concerned, an MVCC snapshot >> would probably be the thing to use anyway; > That surprises me, though. I really thought the point was to cost the > index scan, and surely that wil

Re: [HACKERS] maintenance_work_mem and CREATE INDEX time

2013-07-23 Thread Jeff Janes
On Mon, Jul 22, 2013 at 9:11 PM, Amit Langote wrote: > Hello, > > While understanding the effect of maintenance_work_mem on time taken > by CREATE INDEX, I observed that for the values of > maintenance_work_mem less than the value for which an internal sort is > performed, the time taken by CREATE

Re: [HACKERS] new "row-level lock" error messages

2013-07-23 Thread Alvaro Herrera
Alvaro Herrera wrote: > Peter Eisentraut wrote: > > > I would suggest that these changes be undone, except that the old > > "SELECT FOR ..." be replaced by a dynamic string that reverse-parses the > > LockingClause to provide the actual clause that was used. > > Here's a patch for this. Pushed t

Re: [HACKERS] getting rid of SnapshotNow

2013-07-23 Thread Robert Haas
On Tue, Jul 23, 2013 at 12:28 PM, Tom Lane wrote: > Robert Haas writes: >>> 2. snapshot-self-not-now-v1.patch changes several uses of SnapshotNow >>> to use SnapshotSelf instead. These include pgrowlocks(), >>> pgstat_heap(), and get_actual_variable_range(). > >> Tom proposed that we use Snapsho

Re: [HACKERS] [v9.4] row level security

2013-07-23 Thread Greg Smith
On 7/23/13 12:10 PM, Josh Berkus wrote: Apparently it's a little much for experienced reviewers to chew on, too, since I've been trying to get someone to review it since the beginning of the Commitfest. It's more than the available experienced reviewers are willing to chew on fully as voluntee

Re: [HACKERS] getting rid of SnapshotNow

2013-07-23 Thread Tom Lane
Robert Haas writes: >> 2. snapshot-self-not-now-v1.patch changes several uses of SnapshotNow >> to use SnapshotSelf instead. These include pgrowlocks(), >> pgstat_heap(), and get_actual_variable_range(). > Tom proposed that we use SnapshotDirty for this case; let me just ask > whether there are

Re: [HACKERS] [COMMITTERS] pgsql: Add support for REFRESH MATERIALIZED VIEW CONCURRENTLY.

2013-07-23 Thread Kevin Grittner
Andres Freund wrote: > Hm. There seems to be more things that need some more improvement > from a quick look. > > First, I have my doubts of the general modus operandy of > CONCURRENTLY here. I think in many, many cases it would be faster > to simply swap in the newly built heap + indexes in conc

Re: [HACKERS] Comma Comma Comma 8601

2013-07-23 Thread David E. Wheeler
On Jul 23, 2013, at 1:17 AM, Tom Lane wrote: > Does that create any ambiguities against formats we already support? > I'm worried about examples like this one: > > select 'monday, july 22, 22:30 2013'::timestamptz; > timestamptz > > 2013-07-22 22:30:00-04 > (

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

2013-07-23 Thread Josh Berkus
Greg, > As far as motivating new reviewers goes, let's talk about positive > feedback. Anything that complicates the release notes is a non-starter > because that resource is tightly controlled by a small number of people, > and it's trying to satisfy a lot of purposes. Greg, you're re-arguing

Re: [HACKERS] Design proposal: fsync absorb linear slider

2013-07-23 Thread Greg Smith
On 7/23/13 10:56 AM, Robert Haas wrote: On Mon, Jul 22, 2013 at 11:48 PM, Greg Smith wrote: We know that a 1GB relation segment can take a really long time to write out. That could include up to 128 changed 8K pages, and we allow all of them to get dirty before any are forced to disk with fsyn

Re: [HACKERS] [v9.4] row level security

2013-07-23 Thread Josh Berkus
On 07/22/2013 01:27 PM, Greg Smith wrote: > > Anyone who would like to see RLS committed should consider how you can > get resources to support a skilled PostgreSQL reviewer spending time on > it. (This is a bit much to expect new reviewers to chew on usefully) > I've been working on that here, b

Re: [HACKERS] Bloom Filter lookup for hash joins

2013-07-23 Thread Atri Sharma
On Tue, Jul 23, 2013 at 7:32 PM, Greg Stark wrote: > This exact idea was discussed a whole back. I think it was even implemented. > > The problem Tom raised at the time is that the memory usage of the bloom > filter implies smaller or less efficient hash table. It's difficult to > determine whethe

Re: [HACKERS] getting rid of SnapshotNow

2013-07-23 Thread Robert Haas
On Thu, Jul 18, 2013 at 8:46 AM, Robert Haas wrote: > There seems to be a consensus that we should try to get rid of > SnapshotNow entirely now that we have MVCC catalog scans, so I'm > attaching two patches that together come close to achieving that goal: > > 1. snapshot-error-v1.patch introduces

Re: [HACKERS] Design proposal: fsync absorb linear slider

2013-07-23 Thread Robert Haas
On Mon, Jul 22, 2013 at 11:48 PM, Greg Smith wrote: > Recently I've been dismissing a lot of suggested changes to checkpoint fsync > timing without suggesting an alternative. I have a simple one in mind that > captures the biggest problem I see: that the number of backend and > checkpoint writes

Re: [HACKERS] [9.4 CF 1] And then there were 5

2013-07-23 Thread Robert Haas
On Tue, Jul 23, 2013 at 9:22 AM, Greg Smith wrote: > On 7/23/13 9:06 AM, Robert Haas wrote: >> >> But just BTW, you kind of messed up that CommitFest entry. The link you >> added as a new version of the >> patch was actually to a different patch from the same flock. > > Fixed now, since I find my

Re: [HACKERS] improve Chinese locale performance

2013-07-23 Thread Robert Haas
On Tue, Jul 23, 2013 at 9:42 AM, Craig Ringer wrote: > (Replying on phone, please forgive bad quoting) > > Isn't this pretty much what adopting ICU is supposed to give us? > OS-independent collations? Yes. > I'd be interested in seeing the rest data for this performance report, partly > as I'd

Re: [HACKERS] Performance Improvement by reducing WAL for Update Operation

2013-07-23 Thread Amit Kapila
On Tuesday, July 23, 2013 7:06 PM Andres Freund wrote: > On 2013-07-23 18:59:11 +0530, Amit Kapila wrote: > > > * I'd be very surprised if this doesn't make WAL replay of update > heavy > > > workloads slower by at least factor of 2. > > > > Yes, if you just consider the cost of replay, but i

Re: [HACKERS] Bloom Filter lookup for hash joins

2013-07-23 Thread Greg Stark
This exact idea was discussed a whole back. I think it was even implemented. The problem Tom raised at the time is that the memory usage of the bloom filter implies smaller or less efficient hash table. It's difficult to determine whether you're coming out ahead or behind. I think it should be po

Re: [HACKERS] Performance problem in PLPgSQL

2013-07-23 Thread Tom Lane
Marc Cousin writes: > The example below is of course extremely simplified, and obviously not > what we are really doing in the database, but it exhibits the slowdown > between 9.1.9 and 9.2.4. Hm. Some experimentation shows that the plan cache is failing to switch to a generic plan, but I'm not

Re: [HACKERS] make --silent

2013-07-23 Thread Andres Freund
On 2013-07-23 09:27:18 -0400, Tom Lane wrote: > Andres Freund writes: > > On 2013-07-23 08:38:03 -0400, Peter Eisentraut wrote: > >> In file included from gram.y:13612:0: > >> scan.c: In function ‘yy_try_NUL_trans’: > >> scan.c:10181:23: warning: unused variable ‘yyg’ [-Wunused-variable] > >> Post

Re: [HACKERS] improve Chinese locale performance

2013-07-23 Thread Craig Ringer
(Replying on phone, please forgive bad quoting) Isn't this pretty much what adopting ICU is supposed to give us? OS-independent collations? I'd be interested in seeing the rest data for this performance report, partly as I'd like to see how ICU collations would compare when ICU is crudely hacke

Re: [HACKERS] Performance Improvement by reducing WAL for Update Operation

2013-07-23 Thread Andres Freund
On 2013-07-23 18:59:11 +0530, Amit Kapila wrote: > > * I'd be very surprised if this doesn't make WAL replay of update heavy > > workloads slower by at least factor of 2. > > Yes, if you just consider the cost of replay, but it involves other > operations as well > like for standby case

Re: [HACKERS] make --silent

2013-07-23 Thread Andres Freund
On 2013-07-23 09:21:54 -0400, Stephen Frost wrote: > * Andres Freund (and...@2ndquadrant.com) wrote: > > On 2013-07-23 08:38:03 -0400, Peter Eisentraut wrote: > > > Writing postgres.bki > > > Writing schemapg.h > > > Writing postgres.description > > > Writing postgres.shdescription > > > Writing fm

Re: [HACKERS] Suggestion for concurrent index creation using a single full scan operation

2013-07-23 Thread Andres Freund
On 2013-07-23 14:17:13 +0100, Greg Stark wrote: > We already do this in pg_restore by starting multiple worker processes. > Those processes should get the benefit of synchronised sequential scans. > > The way the api for indexes works y wouldn't really be hard to start > multiple parallel index bu

Re: [HACKERS] Performance Improvement by reducing WAL for Update Operation

2013-07-23 Thread Amit Kapila
On Tuesday, July 23, 2013 12:27 AM Andres Freund wrote: > On 2013-07-19 10:40:01 +0530, Hari Babu wrote: > > > > On Friday, July 19, 2013 4:11 AM Greg Smith wrote: > > >On 7/9/13 12:09 AM, Amit Kapila wrote: > > >>I think the first thing to verify is whether the results posted > can be validate

Re: [HACKERS] make --silent

2013-07-23 Thread Tom Lane
Andres Freund writes: > On 2013-07-23 08:38:03 -0400, Peter Eisentraut wrote: >> I have noticed that some people post examples using make --silent (-s). >> I found this actually kind of neat to use from time to time, because >> then you only see output if you have warnings or errors. But we get >

Re: [HACKERS] [9.4 CF 1] And then there were 5

2013-07-23 Thread Greg Smith
On 7/23/13 9:06 AM, Robert Haas wrote: But just BTW, you kind of messed up that CommitFest entry. The link you added as a new version of the patch was actually to a different patch from the same flock. Fixed now, since I find myself looking back through history on submissions often enough to

Re: [HACKERS] make --silent

2013-07-23 Thread Stephen Frost
* Andres Freund (and...@2ndquadrant.com) wrote: > On 2013-07-23 08:38:03 -0400, Peter Eisentraut wrote: > > Writing postgres.bki > > Writing schemapg.h > > Writing postgres.description > > Writing postgres.shdescription > > Writing fmgroids.h > > Writing fmgrtab.c > > I personally don't feel the n

Re: [HACKERS] Suggestion for concurrent index creation using a single full scan operation

2013-07-23 Thread Greg Stark
We already do this in pg_restore by starting multiple worker processes. Those processes should get the benefit of synchronised sequential scans. The way the api for indexes works y wouldn't really be hard to start multiple parallel index builds. I'm not sure how well the pg_restore thing works and

Re: [HACKERS] [9.4 CF 1] And then there were 5

2013-07-23 Thread Robert Haas
On Tue, Jul 23, 2013 at 12:04 AM, Greg Smith wrote: > A further look at recently ALTER OPERATOR FAMILY changes shows that Robert > has been working on those quite a bit. I'm putting him down as the > committer on this last one. I missed that one, now committed. But just BTW, you kind of messed

Re: [HACKERS] pg_upgrade across more than two neighboring major releases

2013-07-23 Thread Bruce Momjian
On Tue, Jul 23, 2013 at 09:48:16PM +0900, Michael Paquier wrote: > > > > On Tue, Jul 23, 2013 at 8:53 PM, Pavel Raiskup wrote: > > Is pg_upgrade supposed to work even across multiple major releases? (I > know > that the README.rpm-dist is mentioning just one major release step, bu

Re: [HACKERS] Add more regression tests for ALTER OPERATOR FAMILY.. ADD / DROP

2013-07-23 Thread Robert Haas
On Thu, May 23, 2013 at 6:52 PM, Robins wrote: > Please find attached a patch to take code-coverage of ALTER OPERATOR > FAMILY.. ADD / DROP (src/backend/commands/opclasscmds.c) from 50% to 87%. > > Any and all feedback is welcome. Committed. -- Robert Haas EnterpriseDB: http://www.enterprisedb.

Re: [HACKERS] make --silent

2013-07-23 Thread Andres Freund
On 2013-07-23 08:38:03 -0400, Peter Eisentraut wrote: > I have noticed that some people post examples using make --silent (-s). > I found this actually kind of neat to use from time to time, because > then you only see output if you have warnings or errors. But we get > some extra output that does

Re: [HACKERS] Review: UNNEST (and other functions) WITH ORDINALITY

2013-07-23 Thread Dean Rasheed
On 23 July 2013 06:10, Tom Lane wrote: > Andrew Gierth writes: >> I must admit to finding all of this criticism of unread code a bit >> bizarre. > > If you yourself are still finding bugs in the code as of this afternoon, > onlookers could be forgiven for doubting that the code is quite as > read

Re: [HACKERS] pg_upgrade across more than two neighboring major releases

2013-07-23 Thread Michael Paquier
On Tue, Jul 23, 2013 at 8:53 PM, Pavel Raiskup wrote: > Is pg_upgrade supposed to work even across multiple major releases? (I > know > that the README.rpm-dist is mentioning just one major release step, but it > could be bound just to actual pg_upgrade which is packaged..) > Yes you should be a

Re: [HACKERS] proposal - psql - show longest tables

2013-07-23 Thread Stephen Frost
* Tom Lane (t...@sss.pgh.pa.us) wrote: > Even if we thought the functionality was worth the trouble, which I > continue to doubt, this particular syntax proposal is a disaster. Agreed. While there might be things worthwhile to add to psql's backslash commands, this isn't one of those. Th

[HACKERS] make --silent

2013-07-23 Thread Peter Eisentraut
I have noticed that some people post examples using make --silent (-s). I found this actually kind of neat to use from time to time, because then you only see output if you have warnings or errors. But we get some extra output that doesn't quite fit: Writing postgres.bki Writing schemapg.h Writin

Re: [HACKERS] [9.4 CF 1] And then there were 5

2013-07-23 Thread Stephen Frost
Greg, First, thanks for helping out with the CF. * Greg Smith (g...@2ndquadrant.com) wrote: > That leaves only 1 patch where I have no idea who will commit it: > > access to calls stack from GET DIAGNOSTICS statement I'll take a look at this. Thanks again, Stephen

Re: [HACKERS] improve Chinese locale performance

2013-07-23 Thread Robert Haas
On Mon, Jul 22, 2013 at 12:49 PM, Greg Stark wrote: > On Mon, Jul 22, 2013 at 12:50 PM, Peter Eisentraut wrote: >> I think part of the problem is that we call strcoll for each comparison, >> instead of doing strxfrm once for each datum and then just strcmp for >> each comparison. That is effecti

Re: [HACKERS] Performance Improvement by reducing WAL for Update Operation

2013-07-23 Thread Amit Kapila
On Tuesday, July 23, 2013 12:02 AM Greg Smith wrote: > The v3 patch applies perfectly here now. Attached is a spreadsheet > with test results from two platforms, a Mac laptop and a Linux server. > I used systems with high disk speed because that seemed like a worst > case for this improvement. Th

[HACKERS] Suggestion for concurrent index creation using a single full scan operation

2013-07-23 Thread Tim Kane
Hi all, I haven't given this a lot of thought, but it struck me that when rebuilding tables (be it for a restore process, or some other operational activity) - there is more often than not a need to build an index or two, sometimes many indexes, against the same relation. It strikes me that in or

[HACKERS] pg_upgrade across more than two neighboring major releases

2013-07-23 Thread Pavel Raiskup
Hello all, don't know much about pg_upgrade implementation so I rather asking here before I start trying the process once again with debugging and observing deeply the code. I tried to setup our postgresql RPM to package pg_upgrade in version 8.4.13 to automatize post-rpm-upgrade update of postgr

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

2013-07-23 Thread Greg Smith
On 7/23/13 2:16 AM, Satoshi Nagayasu wrote: > I've been working on new pgstattuple function to allow > block sampling [1] in order to reduce block reads while > scanning a table. A PoC patch is attached. Take a look at all of the messages linked in https://commitfest.postgresql.org/action/patch_vi

Re: [HACKERS] Proposal: template-ify (binary) extensions

2013-07-23 Thread Markus Wanner
On 07/16/2013 09:14 PM, I wrote: > But okay, you're saying we *have* and *want* a guarantee that even a > superuser cannot execute arbitrary native code via libpq (at least in > default installs w/o extensions). I stand corrected and have to change my position, again. For the record: We do not ha

[HACKERS] Performance problem in PLPgSQL

2013-07-23 Thread Marc Cousin
Hi, I've been trying to diagnose a severe performance regression we've been having in one of our plpgsql procedures. The example below is of course extremely simplified, and obviously not what we are really doing in the database, but it exhibits the slowdown between 9.1.9 and 9.2.4. So here is t

Re: [HACKERS] LDAP: bugfix and deprecated OpenLDAP API

2013-07-23 Thread Albe Laurenz
Magnus Hagander wrote: > In that case, doesn't this patch break Windows? We no longer do the > anonymous bind on Windows, since it's now in the #ifdef HAVE_LIBLDAP. > > Don't we need to keep the ldap_simple_bind() call in the Windows case, > or break it up so the call to ldap_sasl_bind_s() is moved

Re: [HACKERS] changeset generation v5-01 - Patches & git tree

2013-07-23 Thread Andres Freund
On 2013-07-22 13:50:08 -0400, Robert Haas wrote: > On Fri, Jun 14, 2013 at 6:51 PM, Andres Freund wrote: > > The git tree is at: > > git://git.postgresql.org/git/users/andresfreund/postgres.git branch > > xlog-decoding-rebasing-cf4 > > http://git.postgresql.org/gitweb/?p=users/andresfreund/postgr

Re: [HACKERS] Back branches vs. gcc 4.8.0

2013-07-23 Thread Andres Freund
On 2013-04-29 23:37:43 -0400, Peter Eisentraut wrote: > On Sat, 2013-04-06 at 12:59 -0400, Tom Lane wrote: > > The reason I'm thinking it's a good idea is that it would expose any > > remaining places where we have nominally var-length arrays embedded in > > larger structs. Now that I've seen the

Re: [HACKERS] maintenance_work_mem and CREATE INDEX time

2013-07-23 Thread Amit Langote
On Tue, Jul 23, 2013 at 1:11 PM, Amit Langote wrote: > Hello, > > While understanding the effect of maintenance_work_mem on time taken > by CREATE INDEX, I observed that for the values of > maintenance_work_mem less than the value for which an internal sort is > performed, the time taken by CREATE

Re: [HACKERS] anchovy failing on 9.1 and earlier since using gcc 4.8

2013-07-23 Thread Andres Freund
On 2013-07-23 09:11:00 +0200, Andres Freund wrote: > Hi, > > Anchovy is failing on 9.1 and earlier for quite some time now: > http://pgbuildfarm.org/cgi-bin/show_history.pl?nm=anchovy&br=REL9_1_STABLE > The commit at that date looks rather unconspicuous. Looking at the > 'config' section reveals t

Re: [HACKERS] Using ini file to setup replication

2013-07-23 Thread Sawada Masahiko
On Mon, Jul 22, 2013 at 10:59 PM, Greg Stark wrote: > On Fri, Jul 19, 2013 at 2:20 PM, Samrat Revagade > wrote: > >> for example: >> if i want to configure 2 servers then it will add 6 lines,for 3 -9, for 4-12 >> setting's for particular server will be: >> >> considering the way of setting value

Re: [HACKERS] GSOC13 proposal - extend RETURNING syntax

2013-07-23 Thread Karol Trzcionka
W dniu 23.07.2013 06:22, David Fetter pisze: > What problem or problems did you notice, and what did you change to > fix them? "UPDATE ... FROM" generated "ERROR: variable not found in subplan target lists". I've added some workaround in add_vars_to_targetlist: - if it is an "after" - simple chang

[HACKERS] anchovy failing on 9.1 and earlier since using gcc 4.8

2013-07-23 Thread Andres Freund
Hi, Anchovy is failing on 9.1 and earlier for quite some time now: http://pgbuildfarm.org/cgi-bin/show_history.pl?nm=anchovy&br=REL9_1_STABLE The commit at that date looks rather unconspicuous. Looking at the 'config' section reveals the difference between the failing http://pgbuildfarm.org/cgi-bi

Re: [HACKERS] Design proposal: fsync absorb linear slider

2013-07-23 Thread Peter Geoghegan
On Mon, Jul 22, 2013 at 8:48 PM, Greg Smith wrote: > And I can't get too excited about making this as my volunteer effort when I > consider what the resulting credit will look like. Coding is by far the > smallest part of work like this, first behind coming up with the design in > the first place