Re: [HACKERS] Behaviour of take over the synchronous replication
On Sat, Aug 24, 2013 at 3:14 AM, Josh Berkus j...@agliodbs.com wrote: On 08/23/2013 12:42 AM, Sawada Masahiko wrote: in case (a), those priority is clear. So I think that re-taking over is correct behaviour. OHOT, in case (b), even if AAA and BBB are set same priority, AAA server steals SYNC replication. I think it is better that BBB server continue behaviour SYNC standby, and AAA should become potential server. So, you're saying that: 1) synchronous_standby_names = '*' 2) replica 'BBB' is the current sync standby 3) replica 'AAA' comes online 4) replica 'AAA' grabs sync status ? I'm sorry that you are confuse. It means that 1) synchronous_standby_names = '*' 2) replica 'AAA' is the current sync standby 3) replica 'BBB' is the current async standby (potential sync standby) 4) replica 'AAA' fail. after that, replica 'BBB' is current sync standby. 5) replica 'AAA' comes online 6) replica 'AAA' grabs sync status If that's the case, I'm not really sure that's undesirable behavior. One could argue fairly persuasively that if you care about the precendence order of sync replicas, you shouldn't use '*'. And the rule of if using *, the lowest-sorted replica name has sync is actually a predictable, easy-to-understand rule. So if you want to make this a feature request, you'll need to come up with an argument as to why the current behavior is bad. Otherwise, you're just asking us to document it better (which is a good idea). It is not depend on name of standby server. That is, The standby server, which was connected to the master server during initial configration replication, is top priority even if priority of two server are same. User must remember that which standby server connected to master server at first. I think that this behavior confuse user. so I think that we need to modify this behaviour or if '*' is used, priority of server is not same (modifying manual is also good). Regards, --- Sawada Masahiko
Re: ALTER SYSTEM SET command to change postgresql.conf parameters (RE: [HACKERS] Proposal for Allow postgresql.conf values to be changed via SQL [review])
On Fri, Aug 23, 2013 at 06:41:04PM +0530, Amit Kapila wrote: Not with this proposal... If it's fixed then it makes no sense to make it look like it can be modified. This proposal is to have a special include which user can only use for enable/disable which means he can remove symbol '#' or add '#'. We cannot stop user from changing file name or add some different location, but that can lead to problems. We can have a note on top of this include indicating it is only for enable/disable. Note, my whole purpose for suggesting something like: include_auto_conf_filepostgresql.auto.conf is because I want the file location to be configurable. If I put in my configuration: include_auto_conf_file/etc/postgresql/9.4/postgresql.auto.conf it better put the options there. And if I comment the line out ALTER SYSTEM should stop working. If I put it at the beginning of the config then any other option in the file will override it (which we can detect and warn about). If I put it at the end of the file, ALTER SYSTEM overrides any statically configured options. And I can imagine hosting providers putting the configuration for memory usage, shared library directories and other such options after, and options like cpu_cost, enable_merge_join, etc before. That way they have fine grained control over which options the user can set and which not. I think if we add more meaning to it, like allow user to change it, handling and defining of that will be bit complex. Letting the user configure the location seems like common curtesy. Note this line isn't in itself a GUC, so you can't configure it via ALTER SYSTEM. Have a nice day, -- Martijn van Oosterhout klep...@svana.org http://svana.org/kleptog/ He who writes carelessly confesses thereby at the very outset that he does not attach much importance to his own thoughts. -- Arthur Schopenhauer signature.asc Description: Digital signature
[HACKERS] PL/pgSQL PERFORM with CTE
On Fri, Aug 23, 2013 at 5:07 PM, Tom Lane t...@sss.pgh.pa.us wrote: Josh Berkus j...@agliodbs.com writes: Currently the only way to return query results to the caller is to use some form of RETURN. It is 100% consistent. I don't find it consistent at all, because what that means is that the data is to be returned to the SQL statement that called the function. What's more, the point of any such extension needs to be to allow *multiple* resultsets to be returned to the client --- if you only need one, you can have that functionality today with plain old SELECT FROM myfunction(). And returning some data but continuing execution is surely not consistent with RETURN. With set returning functions, RETURN QUERY etc means 'yield this data' -- which is pretty weird -- so your point only holds true for unadorned return (not RETURN NEXT , RETURN QUERY, etc). So I guess it's hard to claim RETURN means 'return control' though in a procedural sense. In a perfect world, maybe a separate keyword could have been made to distinguish those cases (e.h. YIELD QUERY), so I agree (after some reflection) with the spirit of your point. It's not good to have principle keywords do markedly different things. Basically it seems that we have two choices for how to represent this (hypothetical) future functionality: 1. Define SELECT without INTO as meaning return results directly to client; 2. Invent some new syntax to do it. In a green field I think we'd want to do #2, because #1 seems rather error-prone and unobvious. The only real attraction of #1, IMO, is that it's consistent with T-SQL. But that's not a terribly strong argument given the many existing inconsistencies between T-SQL and plpgsql. Very good points. I think the only compelling case for #1 that could be made would be to improve compatibility with pl/sql -- from what I can see Oracle has not defined the behavior (that is, in pl/sql select must have INTO) but maybe someone could comment on that. BTW, what about INSERT/UPDATE/DELETE RETURNING? Do we want to let these execute and throw away the data? The argument that this would be a feature seems a lot weaker than for SELECT, because after all you could usually just leave off the RETURNING clause. But I'm sure somebody will say they want to put a function with side-effects into RETURNING and then ignore its output. If we agree to relax PERFORM, those should be relaxed on the same basis. In fact, this is conclusive evidence that PERFORM is obsolete: it hails from the days where SELECT was the only data returning DML. merlin
Re: [HACKERS] PL/pgSQL PERFORM with CTE
2013/8/24 Merlin Moncure mmonc...@gmail.com On Fri, Aug 23, 2013 at 5:07 PM, Tom Lane t...@sss.pgh.pa.us wrote: Josh Berkus j...@agliodbs.com writes: Currently the only way to return query results to the caller is to use some form of RETURN. It is 100% consistent. I don't find it consistent at all, because what that means is that the data is to be returned to the SQL statement that called the function. What's more, the point of any such extension needs to be to allow *multiple* resultsets to be returned to the client --- if you only need one, you can have that functionality today with plain old SELECT FROM myfunction(). And returning some data but continuing execution is surely not consistent with RETURN. With set returning functions, RETURN QUERY etc means 'yield this data' -- which is pretty weird -- so your point only holds true for unadorned return (not RETURN NEXT , RETURN QUERY, etc). So I guess it's hard to claim RETURN means 'return control' though in a procedural sense. In a perfect world, maybe a separate keyword could have been made to distinguish those cases (e.h. YIELD QUERY), so I agree (after some reflection) with the spirit of your point. It's not good to have principle keywords do markedly different things. Basically it seems that we have two choices for how to represent this (hypothetical) future functionality: 1. Define SELECT without INTO as meaning return results directly to client; 2. Invent some new syntax to do it. In a green field I think we'd want to do #2, because #1 seems rather error-prone and unobvious. The only real attraction of #1, IMO, is that it's consistent with T-SQL. But that's not a terribly strong argument given the many existing inconsistencies between T-SQL and plpgsql. Very good points. I think the only compelling case for #1 that could be made would be to improve compatibility with pl/sql -- from what I can see Oracle has not defined the behavior (that is, in pl/sql select must have INTO) but maybe someone could comment on that. Oracle has a special function for returning sets from procedures - see a new functionality Implicit Result Sets http://tkyte.blogspot.cz/2013/07/12c-implicit-result-sets.html Although I am thinking so this feature is in T-SQL much more user friendly. Regards Pavel BTW, what about INSERT/UPDATE/DELETE RETURNING? Do we want to let these execute and throw away the data? The argument that this would be a feature seems a lot weaker than for SELECT, because after all you could usually just leave off the RETURNING clause. But I'm sure somebody will say they want to put a function with side-effects into RETURNING and then ignore its output. If we agree to relax PERFORM, those should be relaxed on the same basis. In fact, this is conclusive evidence that PERFORM is obsolete: it hails from the days where SELECT was the only data returning DML. merlin
Re: [HACKERS] Patch for fail-back without fresh backup
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-declaration] syncrep.c:414:6: warning: variable ‘numdataflush’ set but not used [-Wunused-but-set-variable] -- 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] [GENERAL] currval and DISCARD ALL
On Fri, 2013-04-19 at 11:58 -0300, Fabrízio de Royes Mello wrote: Ohh sorry... you're all right... I completely forgot to finish the ReleaseSequenceCaches to transverse 'seqtab' linked list and free each node. The attached patch have this correct code. Please fix this compiler warning: sequence.c:1608:1: warning: no previous prototype for ‘ReleaseSequenceCaches’ [-Wmissing-prototypes] -- 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] Re: Proposal/design feedback needed: WITHIN GROUP (sql standard ordered set aggregate functions)
On Fri, 2013-07-19 at 21:29 +0530, Atri Sharma wrote: Hi all, This is our current work-in-progress patch for WITHIN GROUP. Please fix these compiler warnings: parse_agg.c: In function ‘check_ungrouped_columns_walker’: parse_agg.c:848:3: warning: passing argument 1 of ‘check_ungrouped_columns_walker’ from incompatible pointer type [enabled by default] parse_agg.c:822:1: note: expected ‘struct Node *’ but argument is of type ‘struct List *’ parse_func.c: In function ‘make_fn_arguments’: parse_func.c:1540:9: warning: assignment from incompatible pointer type [enabled by default] parse_func.c:1547:15: warning: assignment from incompatible pointer type [enabled by default] -- 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] Backup throttling
On Wed, 2013-07-24 at 09:20 +0200, Antonin Houska wrote: the purpose of this patch is to limit impact of pg_backup on running server. Feedback is appreciated. Please replace the tabs in the SGML files with spaces. -- 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] pgbench progress report improvements
On Tue, 2013-08-06 at 10:47 +0200, Fabien wrote: Here is a patch submission for reference to the next commitfest. Please replace the tabs in the SGML files with spaces. -- 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] UNNEST with multiple args, and TABLE with multiple funcs
On Tue, 2013-08-13 at 13:54 +, Andrew Gierth wrote: Summary: This patch implements a method for expanding multiple SRFs in parallel that does not have the surprising LCM behaviour of SRFs-in-select-list. (Functions returning fewer rows are padded with nulls instead.) Fails to build in contrib: pg_stat_statements.c -MMD -MP -MF .deps/pg_stat_statements.Po pg_stat_statements.c: In function ‘JumbleRangeTable’: pg_stat_statements.c:1459:27: error: ‘RangeTblEntry’ has no member named ‘funcexpr’ -- 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] Detail part for still waiting for lock log message
On Tue, 2013-08-20 at 19:21 +0300, Tarvi Pillessaar wrote: About patch: Patch is tested against 9.2.4. I was not sure that i should check if the lock holder's proclock was found (as lock holder's proclock should be always there), check is there to be on the safe side, but maybe it's unnecessary. If it's not needed then fallback to old behavior (logging without detail) is not needed as well. And yes, i know that the lock holding time is not actually correct and it actually shows milliseconds since transaction start. Please fix this compiler warning: proc.c: In function ‘ProcSleep’: proc.c:1258:6: warning: ISO C90 forbids mixed declarations and code [-Wdeclaration-after-statement] -- 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] Re: Request for Patch Feedback: Lag Lead Window Functions Can Ignore Nulls
On Wed, 2013-08-21 at 22:34 -0400, Nicholas White wrote: but needs a rebase. See attached - thanks! Please fix these compiler warnings: windowfuncs.c: In function ‘leadlag_common’: windowfuncs.c:366:3: warning: passing argument 1 of ‘bms_initialize’ from incompatible pointer type [enabled by default] In file included from windowfuncs.c:16:0: ../../../../src/include/nodes/bitmapset.h:97:19: note: expected ‘void * (*)(void *, Size)’ but argument is of type ‘void * (*)(struct WindowObjectData *, Size)’ windowfuncs.c:306:8: warning: ‘result’ may be used uninitialized in this function [-Wmaybe-uninitialized] -- 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] Performance problem in PLPgSQL
On 23/08/2013 23:55, Tom Lane wrote: Pavel Stehule pavel.steh...@gmail.com 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 planning (relative to execution costs). As I mentioned upthread, it doesn't seem unreasonable to me to do something quick-and-dirty based on the length of the plan's rangetable. Pretty nearly anything would fix these specific situations where the estimated execution cost is negligible. It's possible that there are more complicated cases where we'll need a more accurate estimate, but we've not seen an example of that yet. 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_cost * (length(plan-rangetable) + 1) which'd mean a custom plan has to be estimated to save a minimum of about 5 cost units (more if more than 1 table is used) before it'll be chosen. I'm tempted to make the multiplier be 1 not 1000, but it seems better to be conservative about changing the behavior until we see how well this works in practice. Objections, better ideas? regards, tom lane No better idea as far as I'm concerned, of course :) But it is a bit tricky to understand what is going on when you get hit by it, and using a very approximated cost of the planning time seems the most logical to me. So I'm all for this solution. -- 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] PL/pgSQL PERFORM with CTE
Pavel Stehule pavel.steh...@gmail.com writes: Oracle has a special function for returning sets from procedures - see a new functionality Implicit Result Sets http://tkyte.blogspot.cz/2013/07/12c-implicit-result-sets.html That article is worth reading, because Tom K. points out exactly why T-SQL's approach is a bad idea compared to returning refcursors. It's not clear to me that we should be in a hurry to go there, much less try to be 100% syntax compatible with it. 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] Performance problem in PLPgSQL
Marc Cousin cousinm...@gmail.com 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_cost * (length(plan-rangetable) + 1) which'd mean a custom plan has to be estimated to save a minimum of about 5 cost units (more if more than 1 table is used) before it'll be chosen. I'm tempted to make the multiplier be 1 not 1000, but it seems better to be conservative about changing the behavior until we see how well this works in practice. Objections, better ideas? No better idea as far as I'm concerned, of course :) But it is a bit tricky to understand what is going on when you get hit by it, and using a very approximated cost of the planning time seems the most logical to me. So I'm all for this solution. I've pushed a patch along this line. I verified it fixes your original example, but maybe you could try it on your real application? http://git.postgresql.org/gitweb/?p=postgresql.git;a=commitdiff;h=005f583ba4e6d4d19b62959ef8e70a3da4d188a5 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
[HACKERS] Call for translations
In anticipation of the release of PostgreSQL 9.3, it is once again time to update the message translations. We are now in a string freeze, which has traditionally been associated with the first release candidate, so it's a good time to do this work now. If you want to help, see http://babel.postgresql.org/ for instructions and other information. If there are already active translation teams, please communicate with them first. The mailing list pgtranslation-translat...@pgfoundry.org is available for general discussion and coordination of translation activities. -- 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] pgbench progress report improvements
Here is a patch submission for reference to the next commitfest.
Please replace the tabs in the SGML files with spaces.
Attached a v2 with tabs replaced by spaces.
--
Fabien.diff --git a/contrib/pgbench/pgbench.c b/contrib/pgbench/pgbench.c
index ad8e272..a90b188 100644
--- a/contrib/pgbench/pgbench.c
+++ b/contrib/pgbench/pgbench.c
@@ -103,7 +103,6 @@ extern int optind;
#define MAXCLIENTS 1024
#endif
-#define LOG_STEP_SECONDS 5 /* seconds between log messages */
#define DEFAULT_NXACTS 10 /* default nxacts */
int nxacts = 0; /* number of transactions per client */
@@ -167,11 +166,11 @@ char *index_tablespace = NULL;
#define SCALE_32BIT_THRESHOLD 2
bool use_log; /* log transaction latencies to a file */
-bool use_quiet; /* quiet logging onto stderr */
int agg_interval; /* log aggregates instead of individual
* transactions */
-int progress = 0; /* thread progress report every this seconds */
+int progress = 5; /* report every this seconds, 0 is quiet */
int progress_nclients = 0; /* number of clients for progress report */
+int progress_nthreads = 0; /* number of threads for progress report */
bool is_connect; /* establish connection for each transaction */
bool is_latencies; /* report per-command latencies */
int main_pid; /* main process id used in log filename */
@@ -214,6 +213,8 @@ typedef struct
int nvariables;
instr_time txn_begin; /* used for measuring transaction latencies */
instr_time stmt_begin; /* used for measuring statement latencies */
+ int64 txn_latencies; /* cumulated latencies */
+ int64 txn_sqlats; /* cumulated square latencies */
bool is_throttled; /* whether transaction throttling is done */
int use_file; /* index in sql_files for this client */
bool prepared[MAX_FILES];
@@ -243,8 +244,10 @@ typedef struct
{
instr_time conn_time;
int xacts;
- int64 throttle_lag;
- int64 throttle_lag_max;
+ int64 latencies;
+ int64 sqlats;
+ int64 throttle_lag;
+ int64 throttle_lag_max;
} TResult;
/*
@@ -347,7 +350,6 @@ usage(void)
-i, --initialize invokes initialization mode\n
-F, --fillfactor=NUM set fill factor\n
-n, --no-vacuum do not run VACUUM after initialization\n
- -q, --quiet quiet logging (one message each 5 seconds)\n
-s, --scale=NUM scaling factor\n
--foreign-keys create foreign key constraints between tables\n
--index-tablespace=TABLESPACE\n
@@ -367,9 +369,8 @@ usage(void)
(default: simple)\n
-n, --no-vacuum do not run VACUUM before tests\n
-N, --skip-some-updates skip updates of pgbench_tellers and pgbench_branches\n
- -P, --progress=NUM show thread progress report every NUM seconds\n
-r, --report-latencies report average latency per command\n
- -R, --rate=SPEC target rate in transactions per second\n
+ -R, --rate=NUM target rate in transactions per second\n
-s, --scale=NUM report this scale factor in output\n
-S, --select-onlyperform SELECT-only transactions\n
-t, --transactions number of transactions each client runs
@@ -382,6 +383,8 @@ usage(void)
-d, --debug print debugging output\n
-h, --host=HOSTNAME database server host or socket directory\n
-p, --port=PORT database server port number\n
+ -P, --progress=NUM show progress report every NUM seconds (default 5)\n
+ -q, --quiet quiet progress report\n
-U, --username=USERNAME connect as specified database user\n
-V, --versionoutput version information, then exit\n
-?, --help show this help, then exit\n
@@ -928,14 +931,18 @@ top:
* Use inverse transform sampling to randomly generate a delay, such
* that the series of delays will approximate a Poisson distribution
* centered on the throttle_delay time.
- *
- * 1000 implies a 6.9 (-log(1/1000)) to 0.0 (log 1.0) delay multiplier.
+ *
+ * 1 implies a 9.2 (-log(1/1)) to 0.0 (log 1) delay multiplier,
+ * and results in a 0.055 % target underestimation bias:
+ *
+ * SELECT 1.0/AVG(-LN(i/1.0)) FROM generate_series(1,1) AS i;
+ * = 1.00055271703266335474
*
* If transactions are too slow or a given wait is shorter than
* a transaction, the next transaction will start right away.
*/
- int64 wait = (int64)
- throttle_delay * -log(getrand(thread, 1, 1000)/1000.0);
+ int64 wait = (int64) (throttle_delay *
+ 1.00055271703 * -log(getrand(thread, 1, 1)/1.0));
thread-throttle_trigger += wait;
@@ -1003,6 +1010,21 @@ top:
}
/*
+ * always record latency under progress or throttling
+ */
+ if ((progress || throttle_delay)
[HACKERS] Unpacking scalar JSON values
Per report of Armin Ronacher, it's not clear how to take a scalar JSON
string and unquote it into a regular Postgres text value, given what
I can see here:
http://www.postgresql.org/docs/9.3/static/functions-json.html
Example:
SELECT 'a json string'::json;
(Although this some problem could play out with other scalar JSON types):
SELECT '4'::json;
SELECT '2.0'::json;
This use cases arises from some of the extant unpacking operations,
such as json_array_elements. It's not that strange to have a value
something something like this in a JSON:
'{tags: [a \ string, b, c]}'
Thoughts?
--
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] Unpacking scalar JSON values
On 08/24/2013 11:36 PM, Daniel Farina wrote:
Per report of Armin Ronacher, it's not clear how to take a scalar JSON
string and unquote it into a regular Postgres text value, given what
I can see here:
http://www.postgresql.org/docs/9.3/static/functions-json.html
Example:
SELECT 'a json string'::json;
(Although this some problem could play out with other scalar JSON types):
SELECT '4'::json;
SELECT '2.0'::json;
This use cases arises from some of the extant unpacking operations,
such as json_array_elements. It's not that strange to have a value
something something like this in a JSON:
'{tags: [a \ string, b, c]}'
Thoughts?
This was discussed to death at some point during development and
the prevailing consensus was that json type is not representing the
underlying structure/class instance/object but a string which encodes
this object
so if you convert a restricted (must comply to JSON Spec) string to
unrestricted string you really just do a NoOp vast.
I guess this is also why the new hstore-based json (jstore ?) class
needs to be
different as it actually *stores* a structured type resulting from
parsing the
json making many things different
For example currently many other things are unintuitive if you expect
stored type to hold the structure the json evaluates to and not just the
evaluated source string:
hannu=# SELECT 'null'::json::text;
text
--
null
(1 row)
hannu=# SELECT '{a:1, a:null}'::json::text;
text
---
{a:1, a:null}
(1 row)
Regards
--
Hannu Krosing
PostgreSQL Consultant
Performance, Scalability and High Availability
2ndQuadrant Nordic OÜ
--
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] Re: Request for Patch Feedback: Lag Lead Window Functions Can Ignore Nulls
Please fix these compiler warnings Fixed - see attached. Thanks - lead-lag-ignore-nulls.patch Description: Binary 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] Parallel pg_basebackup
That looks promising! Thanks Peter! 2013/8/24 Peter Eisentraut pete...@gmx.net On Fri, 2013-08-23 at 10:51 -0300, Emanuel Calvo wrote: I was wondering if there is a proposal for parallelize pg_basebackup There isn't one, but after some talk behind the scenes, I think we should definitely look into it. -- -- Emanuel Calvo
Re: [HACKERS] Unpacking scalar JSON values
On Sat, Aug 24, 2013 at 3:09 PM, Hannu Krosing ha...@2ndquadrant.com wrote:
On 08/24/2013 11:36 PM, Daniel Farina wrote:
Per report of Armin Ronacher, it's not clear how to take a scalar JSON
string and unquote it into a regular Postgres text value, given what
I can see here:
http://www.postgresql.org/docs/9.3/static/functions-json.html
Example:
SELECT 'a json string'::json;
(Although this some problem could play out with other scalar JSON types):
SELECT '4'::json;
SELECT '2.0'::json;
This use cases arises from some of the extant unpacking operations,
such as json_array_elements. It's not that strange to have a value
something something like this in a JSON:
'{tags: [a \ string, b, c]}'
Thoughts?
This was discussed to death at some point during development and
the prevailing consensus was that json type is not representing the
underlying structure/class instance/object but a string which encodes
this object
so if you convert a restricted (must comply to JSON Spec) string to
unrestricted string you really just do a NoOp vast.
This doesn't make a lot of sense to me.
select * from json_each_text('{key: va\lue}'); is handy and gives
one the json value of the text -- that is to say, dequoted. So it's
not like unquoting is not already an operation seen in some of the
operators:
select * from json_each_text('{key: va\lue}');
key | value
-+
key | value
(1 row)
But there's no good way I can find from the documentation to do it
with a scalar: select ('va\lue'::json)::text;
--
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] Unpacking scalar JSON values
On Sat, Aug 24, 2013 at 6:04 PM, Daniel Farina dan...@fdr.io 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
---
va\lue
(1 row)
the JSON escaping is retained. That may be reasonable for a
text-cast, so I'm not suggesting its reinterpretation, but there is no
operator I can identify immediately from the documentation to convert
a JSON string value into a Postgres one like json_each_text, except on
a json that contains a scalar JSON string.
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
[HACKERS] bitset counting as a user defined function in postgresql 9.2?
As an initial attempt to try hands-on with postgresql, I've learned on user created functions and some other internals of postgresql. Few materials on postgresql indicate that the aggregate functions are slow due to some internal reasons (index covering, null etc). I'm looking forward to implement my own bit counting or counting mechanism (I've gone through some bit twiddling as well) via user defined functions (in C) and in cases I may need to create user defined data types as well. Are there any possible scenarios where user defined count would perform better than the underlying implementation? Is it worth a try? And are there any better ways to evaluate, compare both? (other than EXPLAIN ANALYZIS) Please guide. -- Regards, K.Kanarupan Undergraduate, Dept. of Computer Science Engineering University of Moratuwa Mobile: +94 777 420 179
[HACKERS] What is the algorithm used for counting the set bit (number of ones) of a bitmap/bitarray/betset in postgresql?
I've come across lookup tables, Hamming weights and Brain Kernighan's Algo. Are they used (combined or separately) in bitmap counting? Where can I find the coding and please explain the flow a count function (for a bit counting) via coding rather than the high level architectural diagrams (which I'm aware of). I've noted using the below expression to count a particular bits (0 or 1 with minor modification). Could anyone explain at the coding level of postgresql and what algorithms are used? postgres= SELECT LENGTH( REPLACE( CAST( B'10100010' AS TEXT ), '0', '')); Regards, K.Kanarupan Undergraduate,k Dept. of Computer Science Engineering University of Moratuwa Mobile: +94 777 420 179
Re: ALTER SYSTEM SET command to change postgresql.conf parameters (RE: [HACKERS] Proposal for Allow postgresql.conf values to be changed via SQL [review])
On Sat, Aug 24, 2013 at 6:08 PM, Martijn van Oosterhout klep...@svana.org wrote: On Fri, Aug 23, 2013 at 06:41:04PM +0530, Amit Kapila wrote: Not with this proposal... If it's fixed then it makes no sense to make it look like it can be modified. This proposal is to have a special include which user can only use for enable/disable which means he can remove symbol '#' or add '#'. We cannot stop user from changing file name or add some different location, but that can lead to problems. We can have a note on top of this include indicating it is only for enable/disable. Note, my whole purpose for suggesting something like: include_auto_conf_filepostgresql.auto.conf is because I want the file location to be configurable. If I put in my configuration: include_auto_conf_file/etc/postgresql/9.4/postgresql.auto.conf it better put the options there. And if I comment the line out ALTER SYSTEM should stop working. If I put it at the beginning of the config then any other option in the file will override it (which we can detect and warn about). If I put it at the end of the file, ALTER SYSTEM overrides any statically configured options. And I can imagine hosting providers putting the configuration for memory usage, shared library directories and other such options after, and options like cpu_cost, enable_merge_join, etc before. That way they have fine grained control over which options the user can set and which not. Thanks for your suggestion. Above usecase can be achieved even if the file is not configurable. I think if we add more meaning to it, like allow user to change it, handling and defining of that will be bit complex. Letting the user configure the location seems like common curtesy. Note this line isn't in itself a GUC, so you can't configure it via ALTER SYSTEM. In general yes it is better to give control to user for configuring the location, but as this file will be used for internal purpose and will be modified by system and not by user, so it is better to be in data directory. The similar thing was discussed previously on this thread and it is suggested to have this file in data directory. With Regards, Amit Kapila. EnterpriseDB: http://www.enterprisedb.com -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
