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

On Mon, Nov 25, 2013 at 6:55 PM, Robert Haas wrote: > But even if that doesn't > pan out, I think the fallback position should not be "OK, well, if we > can't get decreased I/O for free then forget it" but rather "OK, if we > can't get decreased I/O for free then let's get decreased I/O in > excha

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

On Mon, Jan 20, 2014 at 9:49 PM, Robert Haas wrote: > > I ran Heikki's test suit on latest master and latest master plus > pgrb_delta_encoding_v4.patch on a PPC64 machine, but the results > didn't look too good. The only tests where the WAL volume changed by > more than half a percent were the "o

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

On Mon, Jan 20, 2014 at 5:38 PM, MauMau wrote: > From: "Amit Kapila" >> >> Do you think without this the problem reported by you is resolved >> completely. >> User can hit same problem, if he tries to follow similar steps mentioned >> in >> your first mail. I had tried below steps based on

Re: [HACKERS] inherit support for foreign tables

(2014/01/21 11:44), Shigeru Hanada wrote: Thanks for the comments. 2014/1/21 KaiGai Kohei : In addition, an idea which I can't throw away is to assume that all constraints defined on foreign tables as ASSERTIVE. Foreign tables potentially have dangers to have "wrong" data by updating source da

[HACKERS] proposal: hide application_name from other users

First of all, I apologize for submitting a patch and missing the commitfest deadline. Given the size of the patch, I thought I'd submit it for your consideration regardless. This patch prevents non-superusers from viewing other user's pg_stat_activity.application_name. This topic was discussed so

Re: [HACKERS] NOT Null constraint on foreign table not working

On Mon, Jan 20, 2014 at 8:52 PM, Tom Lane wrote: > Rushabh Lathia writes: > > As per the PG documentation it says that foreign table do support the > > NOT NULL, NULL and DEFAULT. > > There has been a great deal of debate about what constraints on foreign > tables ought to mean. Right now, at l

Re: [HACKERS] [PATCH] Implement json_array_elements_text

On 20 January 2014 18:58, Laurence Rowe wrote: > Following the discussion on pgsql-general, I thought I'd have a go > implementing json_array_elements_text following the same pattern as > json_each_text. > This updated patch makes the return type of ``json_array_elements_text`` text rather than

Re: [HACKERS] dynamic shared memory and locks

(2014/01/11 3:11), Robert Haas wrote: On Mon, Jan 6, 2014 at 5:50 PM, Robert Haas wrote: This is only part of the solution, of course: a complete solution will involve making the hash table key something other than the lock ID. What I'm thinking we can do is making the lock ID consist of two un

Re: [HACKERS] NOT Null constraint on foreign table not working

On Tue, Jan 21, 2014 at 9:32 AM, Tom Lane wrote: > Amit Kapila writes: >> On Mon, Jan 20, 2014 at 8:52 PM, Tom Lane wrote: >>> There has been a great deal of debate about what constraints on foreign >>> tables ought to mean. > >> What is the reason for keeping DEFAULT behaviour different than >>

Re: [HACKERS] NOT Null constraint on foreign table not working

Amit Kapila writes: > On Mon, Jan 20, 2014 at 8:52 PM, Tom Lane wrote: >> There has been a great deal of debate about what constraints on foreign >> tables ought to mean. > What is the reason for keeping DEFAULT behaviour different than > constraints. Right now the behaviour for DEFAULT is if it

Re: [HACKERS] WIP patch (v2) for updatable security barrier views

On 01/21/2014 09:09 AM, KaiGai Kohei wrote: > (2014/01/13 22:53), Craig Ringer wrote: >> On 01/09/2014 11:19 PM, Tom Lane wrote: >>> Dean Rasheed writes: My first thought was that it should just preprocess any security barrier quals in subquery_planner() in the same way as other quals ar

Re: [HACKERS] NOT Null constraint on foreign table not working

On Mon, Jan 20, 2014 at 8:52 PM, Tom Lane wrote: > Rushabh Lathia writes: >> As per the PG documentation it says that foreign table do support the >> NOT NULL, NULL and DEFAULT. > > There has been a great deal of debate about what constraints on foreign > tables ought to mean. Right now, at leas

Re: [HACKERS] [PATCH] Implement json_array_elements_text

On 01/20/2014 09:58 PM, Laurence Rowe wrote: Following the discussion on pgsql-general, I thought I'd have a go implementing json_array_elements_text following the same pattern as json_each_text. The function makes it possible to join elements of a json array onto a table, Can we sneak this ve

[HACKERS] [PATCH] Implement json_array_elements_text

Following the discussion on pgsql-general, I thought I'd have a go implementing json_array_elements_text following the same pattern as json_each_text. The function makes it possible to join elements of a json array onto a table, for example: CREATE TABLE object (name TEXT PRIMARY KEY, properties J

Re: [HACKERS] inherit support for foreign tables

Thanks for the comments. 2014/1/21 KaiGai Kohei : >> In addition, an idea which I can't throw away is to assume that all >> constraints defined on foreign tables as ASSERTIVE. Foreign tables >> potentially have dangers to have "wrong" data by updating source data >> not through foreign tables. T

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

On 20.1.2014 19:30, Heikki Linnakangas wrote: > > Attached is a yet another version, with more bugs fixed and more > comments added and updated. I would appreciate some heavy-testing of > this patch now. If you could re-run the tests you've been using, > that could be great. I've tested the WAL

Re: [HACKERS] inherit support for foreign tables

(2014/01/14 18:24), Shigeru Hanada wrote: 2013/11/18 Tom Lane : Robert Haas writes: I think it's been previously proposed that we have some version of a CHECK constraint that effectively acts as an assertion for query optimization purposes, but isn't actually enforced by the system. I can see

Re: [HACKERS] Add value to error message when size extends

Daniel Erez writes: > Many thanks for the prompt response and the suggestions! > So, regarding the issue of "production quality" you've mentioned, > we understand there are two remaining matters to address: > 1. debug_query_string: >As we can't rely on this flag, is there any alternative we c

Re: [HACKERS] WIP patch (v2) for updatable security barrier views

(2014/01/13 22:53), Craig Ringer wrote: On 01/09/2014 11:19 PM, Tom Lane wrote: Dean Rasheed writes: My first thought was that it should just preprocess any security barrier quals in subquery_planner() in the same way as other quals are preprocessed. But thinking about it further, those quals

Re: [HACKERS] Shave a few instructions from child-process startup sequence

Peter Eisentraut escribió: > src/backend/postmaster/postmaster.c:2255: indent with spaces. > +else > src/backend/postmaster/postmaster.c:2267: indent with spaces. > +break; I just checked the Jenkins page for this patch: http://pgci.eisentraut.org/jenkins/job/postgresql_commitf

Re: [HACKERS] Fix memset usage in pgcrypto

Marko Kreen escribió: > http://www.viva64.com/en/b/0227/ reported that on-stack memset()s > might be optimized away by compilers. Fix it. Just to clarify, this needs to be applied to all branches, right? If so, does the version submitted apply cleanly to all of them? -- Álvaro Herrera

Re: [HACKERS] PoC: Partial sort

Hi, On Tue, Jan 14, 2014 at 5:49 PM, Alexander Korotkov wrote: >On Tue, Jan 14, 2014 at 12:54 AM, Marti Raudsepp wrote: >> I've been trying it out in a few situations. I implemented a new >> enable_partialsort GUC to make it easier to turn on/off, this way it's a lot >> easier to test. The attac

Re: [Lsf-pc] [HACKERS] Linux kernel impact on PostgreSQL performance

On Wed, Jan 15, 2014 at 11:49:09AM +, Mel Gorman wrote: > It may be the case that mmap/madvise is still required to handle a double > buffering problem but it's far from being a free lunch and it has costs > that read/write does not have to deal with. Maybe some of these problems > can be fixed

Re: [HACKERS] Closing commitfest 2013-11

On 20 January 2014 21:24, Alvaro Herrera wrote: > * fault tolerant DROP IF EXISTS > I gave a look and it looks good for application. This wasn't > superceded by a future version, correct? > No, this hasn't been superceded. +1 for applying it. Regards, Dean -- Sent via pgsql-hackers maili

Re: [HACKERS] [PATCH] pg_basebackup: progress report max once per second

18.11.2013 07:53, Sawada Masahiko kirjoitti: On 13 Nov 2013, at 20:51, Mika Eloranta wrote: Prevent excessive progress reporting that can grow to gigabytes of output with large databases. I got error with following scenario. $ initdb -D data -E UTF8 --no-locale /* setting the replication par

Re: [HACKERS] Closing commitfest 2013-11

Alvaro Herrera writes: > With apologies to our beloved commitfest-mace-wielding CFM, commitfest > 2013-11 intentionally still contains a few open patches. I think that > CF is largely being ignored by most people now that we have CF 2014-01 > in progress. If we don't want to do anything about th

Re: [HACKERS] Storing pg_stat_statements query texts externally, pg_stat_statements in core

Peter Geoghegan writes: > On Mon, Jan 20, 2014 at 12:55 PM, Tom Lane wrote: >> BTW, I'm also thinking that the "detected_version" kluge is about ready >> to collapse of its own weight, or at least is clearly going to break in >> future. What we need to do is embed the API version in the C name o

[HACKERS] Closing commitfest 2013-11

With apologies to our beloved commitfest-mace-wielding CFM, commitfest 2013-11 intentionally still contains a few open patches. I think that CF is largely being ignored by most people now that we have CF 2014-01 in progress. If we don't want to do anything about these patches in the immediate fut

Re: [HACKERS] Storing pg_stat_statements query texts externally, pg_stat_statements in core

On Mon, Jan 20, 2014 at 12:55 PM, Tom Lane wrote: > I see this is marked as ready for committer. Where does it stand in > relation to the other long-running thread about "calls under-estimation > propagation"? I was surprised to find that there isn't any CommitFest > entry linked to that thread,

Re: [HACKERS] Storing pg_stat_statements query texts externally, pg_stat_statements in core

Peter Geoghegan writes: > On Sat, Dec 7, 2013 at 9:26 AM, Fujii Masao wrote: >> The patch doesn't apply cleanly against the master due to recent change of >> pg_stat_statements. Could you update the patch? > Revision is attached, including changes recently discussed on other > thread [1] to allo

Re: [HACKERS] Trigger information for auto_explain.

Jaime Casanova wrote: > On Tue, Jan 14, 2014 at 4:25 AM, Kyotaro HORIGUCHI > wrote: > > > > This patch consists of two parts, > > > > 0001_expose_explain_triggers_v1_20140114.patch > > 0002_auto_explain_triggers_v1_20140114.patch > > Documentation will be added later.. > I think documentation

Re: [HACKERS] [BUGS] surprising to_timestamp behavior

Jeevan Chalke writes: >> I went to review this, and found that there's not actually a patch >> attached ... > Attached. Sorry for that. This looks good to me except for one thing: if the upcoming node is a DCH_FX action (ie, turn on fx_mode), I don't think we want to skip whitespace. The origin

Re: [HACKERS] Trigger information for auto_explain.

On Tue, Jan 14, 2014 at 4:25 AM, Kyotaro HORIGUCHI wrote: > > This patch consists of two parts, > > 0001_expose_explain_triggers_v1_20140114.patch > > Expose the code to print out trigger information currently > hidden in ExplainOnePlan(). > > 0002_auto_explain_triggers_v1_20140114.patch > >

Re: [HACKERS] truncating pg_multixact/members

Hi, On 2014-01-20 15:39:33 -0300, Alvaro Herrera wrote: > * The multixact_freeze_table_age value has been set to 5 million. > I feel this is a big enough number that shouldn't cause too much > vacuuming churn, while at the same time not leaving excessive storage > occupied by pg_multixact/members,

Re: [HACKERS] truncating pg_multixact/members

Alvaro Herrera escribió: > Here's a first cut at this. Note I have omitted a setting equivalent to > autovacuum_freeze_max_age, but I think we should have one too. Some more comments on the patch: * I haven't introduced settings to tweak this per table for autovacuum. I don't think those are n

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

but it's a good smoke test. - Heikki gin-packed-postinglists-20140120.patch.gz Description: GNU Zip compressed data -- 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] WAL Rate Limiting

On 17 January 2014 16:30, Heikki Linnakangas wrote: > It occurs to me that this is very similar to the method I proposed in June > to enforce a hard limit on WAL usage, to avoid PANIC caused by running out > of disk space when writing WAL: > > http://www.postgresql.org/message-id/51b095fe.6050...@

Re: [HACKERS] WAL Rate Limiting

On 17 January 2014 16:10, Tom Lane wrote: > Andres Freund writes: >> On 2014-01-17 09:04:54 -0500, Robert Haas wrote: >>> That having been said, I bet it could be done at the tail of >>> XLogInsert(). > >> I don't think there are many locations where this would be ok. Sleeping >> while holding ex

Re: [HACKERS] WAL Rate Limiting

On 17 January 2014 16:34, Heikki Linnakangas wrote: > On 01/17/2014 05:20 PM, Simon Riggs wrote: >> >> + if (RelationNeedsWAL(indexrel)) >> + CHECK_FOR_WAL_BUDGET(); > > > I don't think we need the RelationNeedsWAL tests. If the relation is not > WAL-logged, you won't write muc

Re: [HACKERS] Comment typo in src/backend/command/cluster.c

On Tue, Jan 21, 2014 at 2:13 AM, Sawada Masahiko wrote: > Hi all, > > Attached patch fixes the typo which is in "src/backend/command/cluster.c". Thanks! Committed. Regards, -- Fujii Masao -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscript

[HACKERS] Comment typo in src/backend/command/cluster.c

Hi all, Attached patch fixes the typo which is in "src/backend/command/cluster.c". Regards, --- Sawada Masahiko fix_typo-cluster.patch Description: Binary data -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresq

Re: [HACKERS] truncating pg_multixact/members

Robert Haas escribió: > On Fri, Jan 3, 2014 at 9:11 AM, Alvaro Herrera > wrote: > Yeah, this stuff is definitely underdocumented relative to vacuum right now. I have added a paragraph or two. It's a (probably insufficient) start. I would like to add a sample query to monitor usage, but I just

Re: [HACKERS] ALTER TABLESPACE ... MOVE ALL TO ...

On 20 January 2014 17:00, Stephen Frost wrote: > * Tom Lane (t...@sss.pgh.pa.us) wrote: >> What if you're a superuser and you want to move everybody's objects >> (perhaps in preparation for dropping the tablespace)? I think there's >> value in both the ALL and OWNED forms. > > A superuser is cons

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

On Thu, Jan 16, 2014 at 12:07 AM, Amit Kapila wrote: >Okay, got your point. >Another minor thing is that in latest patch which I have sent yesterday, >I have modified it such that while formation of chunks if there is a data >at end of string which doesn't have special pattern and

Re: [HACKERS] Backup throttling

On 01/15/2014 10:52 PM, Alvaro Herrera wrote: > I gave this patch a look. There was a bug that the final bounds check > for int32 range was not done when there was no suffix, so in effect you > could pass numbers larger than UINT_MAX and pg_basebackup would not > complain until the number reached

Re: [HACKERS] ALTER TABLESPACE ... MOVE ALL TO ...

* Simon Riggs (si...@2ndquadrant.com) wrote: > > ALTER TABLESPACE name MOVE OWNED TO name opt_nowait > > The ALL seems to have value. "MOVE ALL OWNED TO" sounds better. I could go either way on this, really. > > ALTER TABLESPACE name MOVE TABLES OWNED TO name opt_nowait > > ALTER TABLESPACE name

Re: [HACKERS] ALTER TABLESPACE ... MOVE ALL TO ...

* Tom Lane (t...@sss.pgh.pa.us) wrote: > What if you're a superuser and you want to move everybody's objects > (perhaps in preparation for dropping the tablespace)? I think there's > value in both the ALL and OWNED forms. A superuser is considered to 'own' all objects and so 'ALL' and 'OWNED' abo

Re: [HACKERS] ALTER TABLESPACE ... MOVE ALL TO ...

On 20 January 2014 15:46, Stephen Frost wrote: > So you're still looking for an 'OWNED' noise word to be added? To clarify what the command is actually doing. > Also, I > did add the ability to specify types of objects (it's often that we'll > have a "INDEXES" tablespace, so this made sense),

Re: [HACKERS] ALTER TABLESPACE ... MOVE ALL TO ...

Stephen Frost writes: > So you're still looking for an 'OWNED' noise word to be added? Also, I > did add the ability to specify types of objects (it's often that we'll > have a "INDEXES" tablespace, so this made sense), so how about: > ALTER TABLESPACE name MOVE OWNED TO name opt_nowait > ALTER

Re: [HACKERS] NOT Null constraint on foreign table not working

Rushabh Lathia writes: > As per the PG documentation it says that foreign table do support the > NOT NULL, NULL and DEFAULT. There has been a great deal of debate about what constraints on foreign tables ought to mean. Right now, at least for postgres_fdw, they're just taken as documentation of

Re: [Lsf-pc] [HACKERS] Linux kernel impact on PostgreSQL performance

On Mon, 20 Jan 2014 10:51:41 +1100 Dave Chinner wrote: > On Sun, Jan 19, 2014 at 03:37:37AM +0200, Marti Raudsepp wrote: > > On Wed, Jan 15, 2014 at 5:34 AM, Jim Nasby wrote: > > > it's very common to create temporary file data that will never, ever, ever > > > actually NEED to hit disk. Where I

Re: [Lsf-pc] [HACKERS] Linux kernel impact on PostgreSQL performance

On Fri, Jan 17, 2014 at 03:24:01PM -0500, Gregory Smith wrote: > On 1/17/14 10:37 AM, Mel Gorman wrote: > >There is not an easy way to tell. To be 100%, it would require an > >instrumentation patch or a systemtap script to detect when a > >particular page is being written back and track the context

Re: [HACKERS] ALTER TABLESPACE ... MOVE ALL TO ...

* Simon Riggs (si...@2ndquadrant.com) wrote: > Not a good argument since IN CURRENT DATABASE applies to all SQL > commands, so would clearly be unnecessary. I suppose it depends on how you're looking at it. ALTER TABLESPACE ... RENAME, for example, updates a shared catalog and therefore the chang

[HACKERS] change alter user to be a true alias for alter role

the doc say: > ALTER USER is now an alias for ALTER > ROLE > . but alter user lack the following format: > ALTER ROLE name [ IN DATABASE database_name ] SET configuration_parameter{ TO > | = } { > value | DEFAULT } > ALTER ROLE {

Re: [Lsf-pc] [HACKERS] Linux kernel impact on PostgreSQL performance

On Mon, Jan 20, 2014 at 10:51:41AM +1100, Dave Chinner wrote: > On Sun, Jan 19, 2014 at 03:37:37AM +0200, Marti Raudsepp wrote: > > On Wed, Jan 15, 2014 at 5:34 AM, Jim Nasby wrote: > > > it's very common to create temporary file data that will never, ever, ever > > > actually NEED to hit disk. Wh

Re: [HACKERS] plpgsql.warn_shadow

On Jan20, 2014, at 14:05 , Marko Tiikkaja wrote: > On 1/20/14 1:55 PM, Robert Haas wrote: >> On Mon, Jan 20, 2014 at 7:16 AM, Marko Tiikkaja wrote: >>> What's so hard about plpgsql.warnings='all'? Or if the fact that it's a >>> list is your concern, I'm not going to oppose to making it a boolean

Re: [HACKERS] [PATCH] Negative Transition Aggregate Functions (WIP)

On Jan20, 2014, at 08:42 , David Rowley wrote: >> On Mon, Jan 20, 2014 at 2:45 PM, Florian Pflug wrote: >> * An assert that the frame end doesn't move backwards - I realized that >> it is after all easy to do that, if it's done after the loop which adds >> the new values, not before. > > I'v

Re: [HACKERS] ALTER TABLESPACE ... MOVE ALL TO ...

On 20 January 2014 14:24, Stephen Frost wrote: > * Simon Riggs (si...@2ndquadrant.com) wrote: >> The command uses the word ALL but then less than all objects, i.e. >> only moves objects that are owned by the user. > > My thinking was that it was "all" from that user's perspective. > >> I would lik

Re: [HACKERS] array_length(anyarray)

On 20 January 2014 13:47, Marko Tiikkaja wrote: > On 1/20/14 2:29 PM, Dean Rasheed wrote: >> >> I think this is ready for committer > > > Thanks! > >> ... although I would also like to see >> >> the doc changes to make the table of array function descriptions a bit >> more explicit about corner ca

Re: [HACKERS] array_length(anyarray)

On 1/20/14 2:29 PM, Dean Rasheed wrote: I think this is ready for committer Thanks! ... although I would also like to see the doc changes to make the table of array function descriptions a bit more explicit about corner cases. Hmm. I completely missed the fact that unnest() already uses a

Re: [HACKERS] Hstore 2.0 patch

On 01/19/2014 10:31 PM, Rami Grossman wrote: Hi everyone, Is it possible to add the hstore 2.0 patch (and later the json solution) as an extension for 9.3 right now, so we'll not have to wait for 9.4 I can say that this patch is very important for my organisation's large project, they won'

Re: [HACKERS] array_length(anyarray)

On 19 January 2014 11:43, Marko Tiikkaja wrote: > New version attached, without the doc change. > This looks good to me. - applies cleanly. - compiles with no warnings. - passes a sensible set of new regression tests. - implements the agreed behaviour, per SQL spec. - I can't think of any c

Re: [HACKERS] ALTER TABLESPACE ... MOVE ALL TO ...

* Simon Riggs (si...@2ndquadrant.com) wrote: > The command uses the word ALL but then less than all objects, i.e. > only moves objects that are owned by the user. My thinking was that it was "all" from that user's perspective. > I would like to see two variants of this... > > ALL ... which attem

Re: [HACKERS] plpgsql.warn_shadow

On 1/20/14 1:55 PM, Robert Haas wrote: On Mon, Jan 20, 2014 at 7:16 AM, Marko Tiikkaja wrote: What's so hard about plpgsql.warnings='all'? Or if the fact that it's a list is your concern, I'm not going to oppose to making it a boolean. Sure, that'd be fine. What I don't want is to have to s

Re: [HACKERS] plpgsql.warn_shadow

On Mon, Jan 20, 2014 at 7:16 AM, Marko Tiikkaja wrote: > What's so hard about plpgsql.warnings='all'? Or if the fact that it's a > list is your concern, I'm not going to oppose to making it a boolean. Sure, that'd be fine. What I don't want is to have to start each function with: #option warn_

Re: [HACKERS] PoC: Partial sort

On Sun, Jan 19, 2014 at 5:57 AM, Andreas Karlsson wrote: > On 01/18/2014 08:13 PM, Jeremy Harris wrote: > >> On 31/12/13 01:41, Andreas Karlsson wrote: >> >>> On 12/29/2013 08:24 AM, David Rowley wrote: >>> If it was possible to devise some way to reuse any previous tuplesortstate perha

Re: [HACKERS] plpgsql.warn_shadow

On 1/20/14 2:25 AM, Robert Haas wrote: On Fri, Jan 17, 2014 at 5:45 AM, Marko Tiikkaja wrote: I see these as being two are different things. There *is* a need for a full-blown static analyzer for PL/PgSQL, but I don't think it needs to be in core. However, there seems to be a number of pitfal

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

From: "Amit Kapila" Do you think without this the problem reported by you is resolved completely. User can hit same problem, if he tries to follow similar steps mentioned in your first mail. I had tried below steps based on description in your first mail: If user register/unregister d

Re: [HACKERS] Add value to error message when size extends

Hi, Many thanks for the prompt response and the suggestions! So, regarding the issue of "production quality" you've mentioned, we understand there are two remaining matters to address: 1. debug_query_string: As we can't rely on this flag, is there any alternative we can rely on? 2. encapsulati

Re: [HACKERS] [PATCH] Negative Transition Aggregate Functions (WIP)

On Mon, Jan 20, 2014 at 2:45 PM, Florian Pflug wrote: > On Jan19, 2014, at 20:00 , David Rowley wrote: > > I've applied that patch again and put in the sort operators. > > I've push a new version to https://github.com/fgp/postgres/tree/invtrans > which includes > > * A bunch of missing declarati

Re: [HACKERS] improve the help message about psql -F

reasonable，I removed the "set",patch attached. Jov blog: http:amutu.com/blog 2014/1/20 Marti Raudsepp > 2014/1/17 Jov > > but in the psql --help,-F say: > > > >> set field separator (default: "|") > > > if user don't read the offical doc carefully,he can use: > > > >>

[HACKERS] Hstore 2.0 patch

Hi everyone, Is it possible to add the hstore 2.0 patch (and later the json solution) as an extension for 9.3 right now, so we'll not have to wait for 9.4 I can say that this patch is very important for my organisation's large project, they won't approve it as a patch but as extension it will go.

Re: [HACKERS] [PATCH] Negative Transition Aggregate Functions (WIP)

On Jan19, 2014, at 20:00 , David Rowley wrote: > I've applied that patch again and put in the sort operators. I've push a new version to https://github.com/fgp/postgres/tree/invtrans which includes * A bunch of missing declaration for *_inv functions * An assert that the frame end doesn't move

Re: [Lsf-pc] [HACKERS] Linux kernel impact on PostgreSQL performance

On Sun, Jan 19, 2014 at 03:37:37AM +0200, Marti Raudsepp wrote: > On Wed, Jan 15, 2014 at 5:34 AM, Jim Nasby wrote: > > it's very common to create temporary file data that will never, ever, ever > > actually NEED to hit disk. Where I work being able to tell the kernel to > > avoid flushing those f

Re: [HACKERS] Compiling extensions on Windows

Craig Ringer wrote: > Out of personal interest (in pain and suffering) I was recently looking > into how to compile extensions out-of-tree on Windows using Visual > Studio (i.e. no PGXS). > > It looks like the conventional answer to this is "Do a source build of > PG, compile your ext in-tree in c

Re: [Lsf-pc] [HACKERS] Re: Linux kernel impact on PostgreSQL performance (summary v2 2014-1-17)

On 2014-01-17 18:34:25 +, Mel Gorman wrote: > > The scheme that'd allow us is the following: > > When postgres reads a data page, it will continue to first look up the > > page in its shared buffers, if it's not there, it will perform a page > > cache backed read, but instruct that read to imme

Re: [Lsf-pc] [HACKERS] Re: Linux kernel impact on PostgreSQL performance (summary v2 2014-1-17)

On Fri, Jan 17, 2014 at 11:01:15AM -0800, Josh Berkus wrote: > Mel, > Hi, > So we have a few interested parties. What do we need to do to set up > the Collab session? > This is great and thanks! There are two summits of interest here -- LSF/MM which will have all the filesystem, storage and

Re: [HACKERS] ALTER TABLESPACE ... MOVE ALL TO ...

On 16 January 2014 22:37, Stephen Frost wrote: > allow users to more easily move their various objects from > one tablespace to another. Included are docs and a regression test; > I'm happy to improve on both should folks send me suggestions. Sounds good. The command uses the word ALL bu

Re: [Lsf-pc] [HACKERS] Linux kernel impact on PostgreSQL performance

On Mon, Jan 20, 2014 at 1:51 AM, Dave Chinner wrote: >> Postgres is far from being the only application that wants this; many >> people resort to tmpfs because of this: >> https://lwn.net/Articles/499410/ > > Yes, we covered the possibility of using tmpfs much earlier in the > thread, and came to

Re: [HACKERS] Deprecations in authentication

On Sat, Jan 18, 2014 at 2:59 PM, Andrew Dunstan wrote: > > On 01/16/2014 08:01 AM, Magnus Hagander wrote: >> >> >> On Wed, Jan 15, 2014 at 6:57 PM, Tom Lane > > wrote: >> >> Magnus Hagander mailto:mag...@hagander.net>> >> >> writes: >> > One thing I noticed -

Re: [HACKERS] [PATCH] Negative Transition Aggregate Functions (WIP)

On Mon, Jan 20, 2014 at 8:42 PM, David Rowley wrote: > On Mon, Jan 20, 2014 at 2:45 PM, Florian Pflug wrote: > >> * EXPLAIN VERBOSE ANALYZE now shows the max. number of forward aggregate >> transitions per row and aggregate. It's a bit imprecise, because it >> doesn't >> track the count per

Re: [HACKERS] using rpmbuild with PostgreSQL 9.2.6 source code

Hi, On Mon, 2014-01-20 at 15:46 +0800, Sameer Kumar wrote: > I have downloaded the tar source code of PostgreSQL and also the SPEC file. > I am trying to use rpmbuild command but I always get below error: > > error: Failed build dependencies: > uuid-devel is needed by postgresql92-9.2.6

Re: [HACKERS] using rpmbuild with PostgreSQL 9.2.6 source code

> you need installed devel packages > > > I tried to install these packages (uuid-devel and systemd-unit) but yum can not locate these packages. I tried to install selinux-policy but I found out that selinux-policy 3.7.19 is already installed and is the latest package available in Red Hat repositor