Re: [HACKERS] Does larger i/o size make sense?
The big-picture problem with work in this area is that no matter how you do it, any benefit is likely to be both platform- and workload-specific. So the prospects for getting a patch accepted aren't all that bright. Indeed. Would it make sense to have something easier to configure that recompiling postgresql and managing a custom executable, say a block size that could be configured from initdb and/or postmaster.conf, or maybe per-object settings specified at creation time? Note that the block size may also affect the cache behavior, for instance for pure random accesses, more recently accessed tuples can be kept in memory if the pages are smaller. So there are other reasons to play with the blocksize than I/O access times, and an option to do that more easily would help. -- Fabien. -- 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, RAISE and error context
2013/8/22 Marko Tiikkaja ma...@joh.to On 8/22/13 9:08 AM, Pavel Stehule wrote: Probably we can introduce a new level of verbosity, but I am thinking so this behave is reasonable. Everybody who use a VERBOSE level expect lot of balast and it show expected info (context of error) Can be this design good enough for you? I like the idea, but I think this should be a new verbosity level. With this patch you would have to go full VERBOSE just to debug PL/pgSQL code with NOTICEs and DEBUGs in it, and that output then becomes harder to parse with the useless C-code information. do you prepare patch ? Pavel Regards, Marko Tiikkaja
Re: [HACKERS] pg_system_identifier()
After someone in IRC asked if there was an equivalent to MySQL's
server_id, it was noted that we do have a system identifier but it's not
very accessible.
The attached patch implements a pg_system_identifier() function that
exposes it.
Would it make sense for such identifiers be standard UUID
(http://en.wikipedia.org/wiki/UUID)?
Should there be a UUID per cluster? and/or per database, possibly deduce
from the cluster one? Should it be configurable, say from
postgresql.conf?
get_pg_uuid()
get_pg_uuid('template0')
Note that there is a set of uuid functions provided as a module that may
help.
--
Fabien.
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
[HACKERS] Behaviour of take over the synchronous replication
Hi all, I understand that setting synchronous_standby_name to '*' means that all priority of standby server are same. and the standby server, which connected to the master server at first, become SYNC standby, another server become ASYNC standby as potential server. So, how to set the priority to standby server is different between '*' and setting all standby names. For example, if there are two standby servers (AAA and BBB) (a) synchronous_standby_names = 'AAA,BBB' application_name | sync_priority | sync_state --+---+ AAA | 1 | sync BBB | 2 | potential (b) synchronous_standby_names = '*' application_name | sync_priority | sync_state --+---+ AAA | 1 | sync BBB | 1 | potential If the AAA server is failed, BBB server take over SYNC replication. After take over, when AAA server starts, AAA server re-take over SYNC replication from BBB server in both case (a) and case(b). That is, AAA server starts as SYNC server again. 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. What am I missing? Please give me feedback. Regards, --- Sawada Masahiko -- 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] Does larger i/o size make sense?
2013/8/23 Fabien COELHO coe...@cri.ensmp.fr: The big-picture problem with work in this area is that no matter how you do it, any benefit is likely to be both platform- and workload-specific. So the prospects for getting a patch accepted aren't all that bright. Indeed. Would it make sense to have something easier to configure that recompiling postgresql and managing a custom executable, say a block size that could be configured from initdb and/or postmaster.conf, or maybe per-object settings specified at creation time? I love the idea of per-object block size setting according to expected workload; maybe configured by DBA. In case when we have to run sequential scan on large tables, larger block size may have less pain than interruption per 8KB boundary to switch the block being currently focused on, even though random access via index scan loves smaller block size. Note that the block size may also affect the cache behavior, for instance for pure random accesses, more recently accessed tuples can be kept in memory if the pages are smaller. So there are other reasons to play with the blocksize than I/O access times, and an option to do that more easily would help. I see. Uniformed block-size could simplify the implementation, thus no need to worry about a scenario that continuous buffer allocation push out pages to be kept in memory. Thanks, -- KaiGai Kohei kai...@kaigai.gr.jp -- 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, RAISE and error context
On 8/23/13 8:38 AM, Pavel Stehule wrote: 2013/8/22 Marko Tiikkaja ma...@joh.to I like the idea, but I think this should be a new verbosity level. With this patch you would have to go full VERBOSE just to debug PL/pgSQL code with NOTICEs and DEBUGs in it, and that output then becomes harder to parse with the useless C-code information. do you prepare patch ? I should have the time to produce one for the September commitfest, but if you (or anyone else) want to work on this, I won't object. My opinion at this very moment is that we should leave the the DEFAULT verbosity alone and add a new one (call it COMPACT or such) with the suppressed context for non-ERRORs. Regards, Marko Tiikkaja -- 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] Does larger i/o size make sense?
Would it make sense to have something easier to configure that recompiling postgresql and managing a custom executable, say a block size that could be configured from initdb and/or postmaster.conf, or maybe per-object settings specified at creation time? I love the idea of per-object block size setting according to expected workload; My 0.02€: wait to see whether the idea get some positive feedback by core people before investing any time in that... The per object would be a lot of work. A per initdb (so per cluster) setting (block size, wal size...) would much easier to implement, but it impacts for storage format. large tables, larger block size may have less pain than interruption per 8KB boundary to switch the block being currently focused on, even though random access via index scan loves smaller block size. Yep, as Tom noted, this is really workload specific. -- Fabien. -- 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, RAISE and error context
2013/8/23 Marko Tiikkaja ma...@joh.to On 8/23/13 8:38 AM, Pavel Stehule wrote: 2013/8/22 Marko Tiikkaja ma...@joh.to I like the idea, but I think this should be a new verbosity level. With this patch you would have to go full VERBOSE just to debug PL/pgSQL code with NOTICEs and DEBUGs in it, and that output then becomes harder to parse with the useless C-code information. do you prepare patch ? I should have the time to produce one for the September commitfest, but if you (or anyone else) want to work on this, I won't object. My opinion at this very moment is that we should leave the the DEFAULT verbosity alone and add a new one (call it COMPACT or such) with the suppressed context for non-ERRORs. The name is not important. What I would, for DEFAULT verbosity, to see a context when RAISE EXCEPTION is used. It is a bug now, I think Regards Pavel Regards, Marko Tiikkaja
Re: ALTER SYSTEM SET command to change postgresql.conf parameters (RE: [HACKERS] Proposal for Allow postgresql.conf values to be changed via SQL [review])
* Amit Kapila (amit.kapil...@gmail.com) wrote: On Thu, Aug 22, 2013 at 6:06 PM, Stephen Frost sfr...@snowman.net wrote: * Amit Kapila (amit.kapil...@gmail.com) wrote: Enable/Disable reading of auto file - a. Have a new include in postresql.conf #include_auto_conf_filepostgresql.auto.conf as it is a special include, we can read this file relative to data directory. Enable/Disable Alter System command --- This can be achieved in 3 ways: a. Check before executing Alter System if include directive is disabled, then just issue a warning to user and proceed with command. b. Check before executing Alter System if include directive is disabled, then just issue an error and stop. It doesn't make sense for it to be a 'warning' with this- the parameter specifies the file to use. If you don't know what file to use, how you can possibly do anything but return an error? As the file and location are fixed, we can go-ahead and write to it, but I think now we are deciding if someone disables include dir, then we can just disable Alter System, so it is better to return error in such situation. It wouldn't be fixed with this approach. Note that I *like* that about this approach. There are a few other considerations with this- - What should the default be? (Still thinking 'off' myself) default 'off' is a safe option, as it won't allow users to make any change to parameter values until/unless they read from manual, how to use it and what can go wrong, on the other side it will be bit hassle for user to use this command. I think 'on' would be better. Yeah, no, I still think 'off' would be best for this particular option. - What happens if the user specifies 'postgresql.conf'? I'm thinking we would disallow such insanity (as that's what it is, imv..) by having an identifier in the file that this is the PG auto conf file. I think we can detect by name and give error. - Should we have such an identifier in auto.conf to indicate that we created it, to prevent the user from setting it to something they shouldn't? I think if user plays with this file manually, it can lead to problems, that's why earlier we have decided to keep a note on top of file which will indicate, do not edit this file manually. I believe that should be sufficient. I agree that having such a disclaimer at the top of the file is a good idea. I'm not completely convinced that's sufficient but it's certainly better than nothing. - What's the bootstrap mode; iow, if a user enables the option but the file doesn't exist, what do we do? With this approach, I'd be inclined to say we simply create it and put the marker to indicate it's our file. Alter System will create the file if doesn't exist. ... Only if it's enabled though. - Should we allow it to be outside of the data dir? We could simply log an error and ignore the parameter if it's more than a simple filename. This should be an error, the file location and name will be fixed. Not with this proposal... If it's fixed then it makes no sense to make it look like it can be modified. Thanks, Stephen signature.asc Description: Digital signature
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 6:01 PM, Stephen Frost sfr...@snowman.net wrote: * Amit Kapila (amit.kapil...@gmail.com) wrote: On Thu, Aug 22, 2013 at 6:06 PM, Stephen Frost sfr...@snowman.net wrote: * Amit Kapila (amit.kapil...@gmail.com) wrote: Enable/Disable reading of auto file - a. Have a new include in postresql.conf #include_auto_conf_filepostgresql.auto.conf as it is a special include, we can read this file relative to data directory. Enable/Disable Alter System command --- This can be achieved in 3 ways: a. Check before executing Alter System if include directive is disabled, then just issue a warning to user and proceed with command. b. Check before executing Alter System if include directive is disabled, then just issue an error and stop. It doesn't make sense for it to be a 'warning' with this- the parameter specifies the file to use. If you don't know what file to use, how you can possibly do anything but return an error? As the file and location are fixed, we can go-ahead and write to it, but I think now we are deciding if someone disables include dir, then we can just disable Alter System, so it is better to return error in such situation. It wouldn't be fixed with this approach. Note that I *like* that about this approach. There are a few other considerations with this- - What should the default be? (Still thinking 'off' myself) default 'off' is a safe option, as it won't allow users to make any change to parameter values until/unless they read from manual, how to use it and what can go wrong, on the other side it will be bit hassle for user to use this command. I think 'on' would be better. Yeah, no, I still think 'off' would be best for this particular option. - What happens if the user specifies 'postgresql.conf'? I'm thinking we would disallow such insanity (as that's what it is, imv..) by having an identifier in the file that this is the PG auto conf file. I think we can detect by name and give error. - Should we have such an identifier in auto.conf to indicate that we created it, to prevent the user from setting it to something they shouldn't? I think if user plays with this file manually, it can lead to problems, that's why earlier we have decided to keep a note on top of file which will indicate, do not edit this file manually. I believe that should be sufficient. I agree that having such a disclaimer at the top of the file is a good idea. I'm not completely convinced that's sufficient but it's certainly better than nothing. - What's the bootstrap mode; iow, if a user enables the option but the file doesn't exist, what do we do? With this approach, I'd be inclined to say we simply create it and put the marker to indicate it's our file. Alter System will create the file if doesn't exist. ... Only if it's enabled though. Yes. - Should we allow it to be outside of the data dir? We could simply log an error and ignore the parameter if it's more than a simple filename. This should be an error, the file location and name will be fixed. 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. I think if we add more meaning to it, like allow user to change it, handling and defining of that will be bit complex. 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
[HACKERS] Parallel pg_basebackup
Hi guys, I was wondering if there is a proposal for parallelize pg_basebackup (sorry if there is already one, I looked into the inbox and did not find any). I made a simple test and the performance gain is pretty considerable using parallel rsync processes vs. single pg_basebackup. i.e., for 46GB of data I had the following results: Using https://gist.github.com/rcoup/5358786: rsync, parallel, including the xlogs real 18m52.674s user 33m54.728s sys 13m44.604s (-x option) real23m26.802s user0m24.392s sys 3m55.116s Actually, AWS services limits the bandwidth per process but if you have parallel processes, none of them will have the IOPS decreased which will be translated in a great improvement. Also the network bandwidth is strong between the regions. Thanks guys! -- -- Emanuel Calvo
Re: [HACKERS] Does larger i/o size make sense?
On Thu, Aug 22, 2013 at 8:53 PM, Kohei KaiGai kai...@kaigai.gr.jp wrote: An idea that I'd like to investigate is, PostgreSQL allocates a set of continuous buffers to fit larger i/o size when block is referenced due to sequential scan, then invokes consolidated i/o request on the buffer. It probably make sense if we can expect upcoming block references shall be on the neighbor blocks; that is typical sequential read workload. I think it makes more sense to use scatter gather i/o or async i/o to read to regular sized buffers scattered around memory than to restrict the buffers to needing to be contiguous. As others said, Postgres depends on the OS buffer cache to do readahead. The scenario where the above becomes interesting is if it's paired with a move to directio or other ways of skipping the buffer cache. Double caching is a huge waste and leads to lots of inefficiencies. The blocking issue there is that Postgres doesn't understand much about the underlying hardware storage. If there were APIs to find out more about it from the kernel -- how much further before the end of the raid chunk, how much parallelism it has, how congested the i/o channel is, etc -- then Postgres might be on par with the kernel and able to eliminate the double buffering inefficiency and might even be able to do better if it understands its own workload better. If Postgres did that then it would be necessary to be able to initiate i/o on multiple buffers in parallel. That can be done using scatter gather i/o such as readv() and writev() but that would mean blocking on reading blocks that might not be needed until the future. Or it could be done using libaio to initiate i/o and return control as soon as the needed data is available while other i/o is still pending. -- greg
Re: [HACKERS] pg_system_identifier()
Vik Fearing vik.fear...@dalibo.com writes: The attached patch implements a pg_system_identifier() function that exposes it. It's information about the server that's only accessible through pg_controldata. I don't know if that's justification enough, which is why I didn't add it to the commitfest yet. We already have two extensions to expose pg_controldata output at the SQL level, and I think we should just include the facility in core. https://github.com/jconway/pg_controldata http://labs.omniti.com/labs/pgtreats/browser/trunk/contrib/control Regards, -- Dimitri Fontaine http://2ndQuadrant.fr PostgreSQL : Expertise, Formation et Support -- 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] pg_system_identifier()
On 08/22/2013 06:37 PM, Tom Lane wrote: A Do we have a reliable way of generating a unique identifier for each slave (independently of how that might be exposed)? Probably we could just generate an unique UUID when we first detect that we are replicating from the master with same UUID. This of course requires this master UUID to be present in some way in the replication stream Cheers -- 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] pg_system_identifier()
This doesn't generate a unique id. You could back up a standby and restore it and point it at the original master and end up with two standbies with the same id. On Fri, Aug 23, 2013 at 4:08 PM, Hannu Krosing ha...@2ndquadrant.comwrote: On 08/22/2013 06:37 PM, Tom Lane wrote: A Do we have a reliable way of generating a unique identifier for each slave (independently of how that might be exposed)? Probably we could just generate an unique UUID when we first detect that we are replicating from the master with same UUID. This of course requires this master UUID to be present in some way in the replication stream Cheers -- 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 -- greg
Re: [HACKERS] pg_system_identifier()
On Fri, Aug 23, 2013 at 3:10 AM, Fabien COELHO coe...@cri.ensmp.fr wrote:
After someone in IRC asked if there was an equivalent to MySQL's
server_id, it was noted that we do have a system identifier but it's not
very accessible.
The attached patch implements a pg_system_identifier() function that
exposes it.
Would it make sense for such identifiers be standard UUID
(http://en.wikipedia.org/wiki/UUID)?
Should there be a UUID per cluster? and/or per database, possibly deduce
from the cluster one? Should it be configurable, say from postgresql.conf?
get_pg_uuid()
get_pg_uuid('template0')
Note that there is a set of uuid functions provided as a module that may
help.
There is sense to this, sure.
I'd think that constructing a Type 5 (SHA-1) UUID based on some local
information would make a lot of sense.
In effect, based on constructing SHA-1 on a string looking like:
Database system identifier: 5651554613500795646
Maximum data alignment: 8
Database block size: 8192
WAL block size: 8192
Maximum length of identifiers:64
Date/time type storage: 64-bit integers
Version: PostgreSQL 9.1.1 on x86_64-unknown-linux-gnu, compiled by
gcc (Debian 4.6.1-4) 4.6.1, 64-bit
== SHA-1 of b1b012cc85149d2fe4bf0fc18c38dcf1218e95a5
(Note that I didn't put anything into that which is mutable such as
port numbers, MAC addresses, or IP
addresses - seems to introduce risk of false-negatives to me...)
--
When confronted by a difficult problem, solve it by reducing it to the
question, How would the Lone Ranger handle this?
--
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] pg_system_identifier()
Christopher Browne cbbro...@gmail.com writes: On Fri, Aug 23, 2013 at 3:10 AM, Fabien COELHO coe...@cri.ensmp.fr wrote: Would it make sense for such identifiers be standard UUID (http://en.wikipedia.org/wiki/UUID)? There is sense to this, sure. That ship's already sailed, though. As was pointed out upthread, we don't really want to change the way that pg_controldata prints the system ID, and we don't want this SQL function printing something different either. I'd think that constructing a Type 5 (SHA-1) UUID based on some local information would make a lot of sense. In effect, based on constructing SHA-1 on a string looking like: Database system identifier: 5651554613500795646 Maximum data alignment: 8 Database block size: 8192 WAL block size: 8192 Maximum length of identifiers:64 Date/time type storage: 64-bit integers Version: PostgreSQL 9.1.1 on x86_64-unknown-linux-gnu, compiled by gcc (Debian 4.6.1-4) 4.6.1, 64-bit == SHA-1 of b1b012cc85149d2fe4bf0fc18c38dcf1218e95a5 Including the version string would be a seriously bad idea --- you don't want the sys ID to change just because you did a minor version upgrade, or even recompiled the same version with a newer compiler, do you? There might be some point in factoring in those other values, but I'm not terribly excited about them either. 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] [PATCH] pg_sleep(interval)
On 8/16/13 7:52 PM, Tom Lane wrote:
I think the gripe here is that pg_sleep('42') has worked for
many releases now, and if we add this patch then it would suddenly
stop working. How common is that usage likely to be (probably not
very), and how useful is it to have a version of pg_sleep that
takes an interval (probably also not very)?
I think it's always going to be a problem going from a function with
only one signature to more than one. It's not going to be a problem
going from two to more.
For example, if you had foo(point) and much later you want to add
foo(box), someone might complain that foo('(1,2)') has worked for many
releases now, and how common is that use? If we had started out with
foo(point) and foo(line) simultaneously, this wouldn't have become a
problem.
This is quite a silly situation. I don't know a good answer, except
either ignoring the problem or requiring that any new function has at
least two overloaded variants. ;-)
--
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, But it can have a different reason. In T-SQL (Microsoft or Sybase) or MySQL a unbound query is used to direct transfer data to client side. Are you planning to implement that in PL/pgSQL? Currently, PL/pgSQL requires RETURN in order to return a query result to the caller. Is there some reason we'd change that? If you're implementing TSQL-for-PostgreSQL, of course you might want to have different behavior with SELECT. However, TSQL is not PL/pgSQL. -- Josh Berkus PostgreSQL Experts Inc. http://pgexperts.com -- 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
It just inserts nb records in a loop in 4 different maneers: - Directly in an int field - Then in a numeric field (that's where we're having problems) - Then in the same numeric field, but trying a cast (it doesn't change a thing) - Then tries with an intermediary temp variable of numeric type (which solves the problem). Here are the runtimes (tables were truncated beforehand): 9.1.9: select test_insert(100); NOTICE: time for int:00:00:09.526009 NOTICE: time for numeric:00:00:10.557126 NOTICE: time for numeric, casted:00:00:10.821369 NOTICE: time for numeric with tmp variable:00:00:10.850847 9.2.4: select test_insert(100); NOTICE: time for int:00:00:09.477044 NOTICE: time for numeric:00:00:24.757032 NOTICE: time for numeric, casted:00:00:24.791016 NOTICE: time for numeric with tmp variable:00:00:10.89332 I really don't know exactly where the problem comes from… but it's been hurting a function very badly (there are several of these static queries with types mismatch). And of course, the problem is not limited to numeric… text has the exact same problem. Regards, Marc I got the same problem today. Unfortunately, we need to rollback to 9.1 in our production site. Of course the team needed to make better tests before go to production. Of course they really need to write better functions in PL/pgSQL, but this problem was a really no go for us. Just don't let this gotcha gone in our to do. -- Regards, Fábio Telles Rodriguez blog: http:// http://www.midstorm.org/~telles/shttp://tellesr.wordpress.com/ avepoint.blog.br e-mail / gtalk / MSN: fabio.tel...@gmail.com Skype: fabio_telles Timbira - The Brazilian Postgres Company http://www.timbira.com.br
Re: [HACKERS] Behaviour of take over the synchronous replication
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 ? 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). -- Josh Berkus PostgreSQL Experts Inc. http://pgexperts.com -- 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
On Fri, Aug 23, 2013 at 12:51 PM, Josh Berkus j...@agliodbs.com wrote: Pavel, But it can have a different reason. In T-SQL (Microsoft or Sybase) or MySQL a unbound query is used to direct transfer data to client side. Are you planning to implement that in PL/pgSQL? Currently, PL/pgSQL requires RETURN in order to return a query result to the caller. Is there some reason we'd change that? If you're implementing TSQL-for-PostgreSQL, of course you might want to have different behavior with SELECT. However, TSQL is not PL/pgSQL. I don't think Pavel's point makes sense in the context of functions. With stored procedures it might though -- but I don't see why that we need to reserve behavior for SELECT without INTO -- it can behave differently when executed with a hypothetical CALL. merlin -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
[HACKERS] A note about bug #8393
I looked into the problem reported here: http://www.postgresql.org/message-id/e1vcmgf-0001uf...@wrigleys.postgresql.org What's happening is that the Var that represents my_col in the outer query has typmod -1, but after we inline the SQL function we can see that what it returns is varchar(5), so build_physical_tlist generates a Var with a positive typmod to represent the sub-select's output, and then locate_grouping_columns fails to match that to the original Var. It's a bit surprising that we've not seen any reports like this before. The failure is hidden in many similar cases because if the inlined subquery is pulled up, the Vars referencing it will be replaced with subquery outputs. But that still leaves a pretty fair number of cases where you could see the failure. I don't see any very nice way to eliminate the potential mismatch of typmods, so what I'm thinking is that locate_grouping_columns shouldn't use tlist_member() (which compares using equal()) to search the physical tlist for a match. Rather, it can depend on the fact that the grouping column must be a Var (cf. make_subplanTargetList) and just look for a Var with the same varno/varattno. Anyone have a better idea? 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] PL/pgSQL PERFORM with CTE
2013/8/23 Josh Berkus j...@agliodbs.com Pavel, But it can have a different reason. In T-SQL (Microsoft or Sybase) or MySQL a unbound query is used to direct transfer data to client side. Are you planning to implement that in PL/pgSQL? yes. I would to see a stored procedures with this functionality in pg Currently, PL/pgSQL requires RETURN in order to return a query result to the caller. Is there some reason we'd change that? it is different functionality. If you're implementing TSQL-for-PostgreSQL, of course you might want to have different behavior with SELECT. However, TSQL is not PL/pgSQL. I don't would to implement T-SQL. Same functionality has a PSM in MySQL. And in this moment, there is not any blocker why this should not be in Postgres. Regards Pavel -- Josh Berkus PostgreSQL Experts Inc. http://pgexperts.com
Re: [HACKERS] PL/pgSQL PERFORM with CTE
2013/8/23 Merlin Moncure mmonc...@gmail.com On Fri, Aug 23, 2013 at 12:51 PM, Josh Berkus j...@agliodbs.com wrote: Pavel, But it can have a different reason. In T-SQL (Microsoft or Sybase) or MySQL a unbound query is used to direct transfer data to client side. Are you planning to implement that in PL/pgSQL? Currently, PL/pgSQL requires RETURN in order to return a query result to the caller. Is there some reason we'd change that? If you're implementing TSQL-for-PostgreSQL, of course you might want to have different behavior with SELECT. However, TSQL is not PL/pgSQL. I don't think Pavel's point makes sense in the context of functions. With stored procedures it might though -- but I don't see why that we need to reserve behavior for SELECT without INTO -- it can behave differently when executed with a hypothetical CALL. I think so is not good if some programming language functionality does one in one context (functions) and does something else in second context (procedures). On second hand, I am thinking so requirement PERFORM is good. A query that does some, but result is ignored, is strange (and it can be a performance fault), so we should not be too friendly in this use case. PERFORM must be fixed, but should be used. Regards Pavel merlin
Re: [HACKERS] PL/pgSQL PERFORM with CTE
On Fri, Aug 23, 2013 at 1:38 PM, Pavel Stehule pavel.steh...@gmail.com wrote: 2013/8/23 Merlin Moncure mmonc...@gmail.com I think so is not good if some programming language functionality does one in one context (functions) and does something else in second context (procedures). It's not really different -- it means 'return if able'. Also there are a lot of things that would have to be different for other reasons especially transaction management. It's not reasonable to expect same behavior in function vs procedure context -- especially in terms of sending output to the caller. On second hand, I am thinking so requirement PERFORM is good. A query that does some, but result is ignored, is strange (and it can be a performance fault), so we should not be too friendly in this use case. Completely disagree. There are many cases where this is *not* strange. For example: SELECT writing_func(some_col) FROM foo; merlin -- 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
2013/8/23 Fábio Telles Rodriguez fabio.tel...@gmail.com It just inserts nb records in a loop in 4 different maneers: - Directly in an int field - Then in a numeric field (that's where we're having problems) - Then in the same numeric field, but trying a cast (it doesn't change a thing) - Then tries with an intermediary temp variable of numeric type (which solves the problem). Here are the runtimes (tables were truncated beforehand): 9.1.9: select test_insert(100); NOTICE: time for int:00:00:09.526009 NOTICE: time for numeric:00:00:10.557126 NOTICE: time for numeric, casted:00:00:10.821369 NOTICE: time for numeric with tmp variable:00:00:10.850847 9.2.4: select test_insert(100); NOTICE: time for int:00:00:09.477044 NOTICE: time for numeric:00:00:24.757032 NOTICE: time for numeric, casted:00:00:24.791016 NOTICE: time for numeric with tmp variable:00:00:10.89332 I really don't know exactly where the problem comes from… but it's been hurting a function very badly (there are several of these static queries with types mismatch). And of course, the problem is not limited to numeric… text has the exact same problem. Regards, Marc I got the same problem today. Unfortunately, we need to rollback to 9.1 in our production site. Of course the team needed to make better tests before go to production. Of course they really need to write better functions in PL/pgSQL, but this problem was a really no go for us. please, can you send a self explained test this issue should be fixed, and we need a examples. Just don't let this gotcha gone in our to do. -- Regards, Fábio Telles Rodriguez blog: http:// http://www.midstorm.org/~telles/shttp://tellesr.wordpress.com/ avepoint.blog.br e-mail / gtalk / MSN: fabio.tel...@gmail.com Skype: fabio_telles Timbira - The Brazilian Postgres Company http://www.timbira.com.br
Re: [HACKERS] PL/pgSQL PERFORM with CTE
2013/8/23 Merlin Moncure mmonc...@gmail.com On Fri, Aug 23, 2013 at 1:38 PM, Pavel Stehule pavel.steh...@gmail.com wrote: 2013/8/23 Merlin Moncure mmonc...@gmail.com I think so is not good if some programming language functionality does one in one context (functions) and does something else in second context (procedures). It's not really different -- it means 'return if able'. Also there are a lot of things that would have to be different for other reasons especially transaction management. It's not reasonable to expect same behavior in function vs procedure context -- especially in terms of sending output to the caller. On second hand, I am thinking so requirement PERFORM is good. A query that does some, but result is ignored, is strange (and it can be a performance fault), so we should not be too friendly in this use case. Completely disagree. There are many cases where this is *not* strange. For example: SELECT writing_func(some_col) FROM foo; it is about a personal taste - if you prefer more verbose or less verbose languages. I feeling a PERFORM usage as something special and you example is nice case, where I am think so PERFORM is good for verbosity. Regards Pavel merlin
Re: [HACKERS] PL/pgSQL PERFORM with CTE
On Aug 23, 2013, at 8:51 PM, Pavel Stehule pavel.steh...@gmail.com wrote: it is about a personal taste - if you prefer more verbose or less verbose languages. I feeling a PERFORM usage as something special and you example is nice case, where I am think so PERFORM is good for verbosity. I really do not see the point of PERFORM in the current implementation of PL/pgSQL. If we were to allow SELECT to run when it is not returning a value or selecting into a variable, it would be unambiguous, since the other two cases require: * Using RETURN (or RETURN QUERY) * The INTO clause I have come around to the position that I think Tom, Josh, and Merlin have all put forward, that PERFORM is unnecessary. Unless Jan chimes in with something the rest of us have missed, it’s starting to feel like a consensus to me, other than your objections, of course. Best, David -- 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
2013/8/23 David E. Wheeler da...@justatheory.com On Aug 23, 2013, at 8:51 PM, Pavel Stehule pavel.steh...@gmail.com wrote: it is about a personal taste - if you prefer more verbose or less verbose languages. I feeling a PERFORM usage as something special and you example is nice case, where I am think so PERFORM is good for verbosity. I really do not see the point of PERFORM in the current implementation of PL/pgSQL. If we were to allow SELECT to run when it is not returning a value or selecting into a variable, it would be unambiguous, since the other two cases require: * Using RETURN (or RETURN QUERY) * The INTO clause I have come around to the position that I think Tom, Josh, and Merlin have all put forward, that PERFORM is unnecessary. Unless Jan chimes in with something the rest of us have missed, it’s starting to feel like a consensus to me, other than your objections, of course. ook Regards Pavel Best, David
Re: [HACKERS] [PATCH] pg_sleep(interval)
For example, if you had foo(point) and much later you want to add
foo(box), someone might complain that foo('(1,2)') has worked for many
releases now, and how common is that use? If we had started out with
foo(point) and foo(line) simultaneously, this wouldn't have become a
problem.
You may provide foo(TEXT) along foo(box) so that foo('(1,2)') works as it
did before.
--
Fabien.
--
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
On 08/23/2013 11:30 AM, Pavel Stehule wrote: 2013/8/23 Josh Berkus j...@agliodbs.com Pavel, But it can have a different reason. In T-SQL (Microsoft or Sybase) or MySQL a unbound query is used to direct transfer data to client side. Are you planning to implement that in PL/pgSQL? yes. I would to see a stored procedures with this functionality in pg Is there some reason we wouldn't use RETURN QUERY in that case, instead of SELECT? As I said above, it would be more consistent with existing PL/pgSQL. -- Josh Berkus PostgreSQL Experts Inc. http://pgexperts.com -- 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
On 2013-08-23 22:02, Josh Berkus wrote: On 08/23/2013 11:30 AM, Pavel Stehule wrote: 2013/8/23 Josh Berkus j...@agliodbs.com Pavel, But it can have a different reason. In T-SQL (Microsoft or Sybase) or MySQL a unbound query is used to direct transfer data to client side. Are you planning to implement that in PL/pgSQL? yes. I would to see a stored procedures with this functionality in pg Is there some reason we wouldn't use RETURN QUERY in that case, instead of SELECT? As I said above, it would be more consistent with existing PL/pgSQL. How would using the same syntax to do an entirely different thing be consistent? Regards, Marko Tiikkaja -- 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
On 08/23/2013 01:06 PM, Marko Tiikkaja wrote: Is there some reason we wouldn't use RETURN QUERY in that case, instead of SELECT? As I said above, it would be more consistent with existing PL/pgSQL. How would using the same syntax to do an entirely different thing be consistent? Currently the only way to return query results to the caller is to use some form of RETURN. It is 100% consistent. -- Josh Berkus PostgreSQL Experts Inc. http://pgexperts.com -- 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
2013/8/23 Josh Berkus j...@agliodbs.com On 08/23/2013 11:30 AM, Pavel Stehule wrote: 2013/8/23 Josh Berkus j...@agliodbs.com Pavel, But it can have a different reason. In T-SQL (Microsoft or Sybase) or MySQL a unbound query is used to direct transfer data to client side. Are you planning to implement that in PL/pgSQL? yes. I would to see a stored procedures with this functionality in pg Is there some reason we wouldn't use RETURN QUERY in that case, instead of SELECT? As I said above, it would be more consistent with existing PL/pgSQL. for example - multirecordset support. can be reason why distinguish between these syntax and these functionality. Regards Pavel -- Josh Berkus PostgreSQL Experts Inc. http://pgexperts.com
Re: [HACKERS] Redesigning checkpoint_segments
On 03.07.2013 21:28, Peter Eisentraut wrote: On 6/6/13 4:09 PM, Heikki Linnakangas wrote: Here's a patch implementing that. Docs not updated yet. I did not change the way checkpoint_segments triggers checkpoints - that'll can be a separate patch. This only decouples the segment preallocation behavior from checkpoint_segments. With the patch, you can set checkpoint_segments really high, without consuming that much disk space all the time. I don't understand what this patch, by itself, will accomplish in terms of the originally stated goals of making checkpoint_segments easier to tune, and controlling disk space used. To some degree, it makes both of these things worse, because you can no longer use checkpoint_segments to control the disk space. Instead, it is replaced by magic. The patch addressed the third point in my first post: A third point is that even if you have 10 GB of disk space reserved for WAL, you don't want to actually consume all that 10 GB, if it's not required to run the database smoothly. There are several reasons for that: backups based on a filesystem-level snapshot are larger than necessary, if there are a lot of preallocated WAL segments and in a virtualized or shared system, there might be other VMs or applications that could make use of the disk space. On the other hand, you don't want to run out of disk space while writing WAL - that can lead to a PANIC in the worst case. What sort of behavior are you expecting to come out of this? In testing, I didn't see much of a difference. Although I'd expect that this would actually preallocate fewer segments than the old formula. For example, if you set checkpoint_segments to 200, and you temporarily generate 100 segments of WAL during an initial data load, but the normal workload generates only 20 segments between checkpoints. Without the patch, you will permanently have about 120 segments in pg_xlog, created by the spike. With the patch, the extra segments will be gradually removed after the data load, down to the level needed by the constant workload. That would be about 50 segments, assuming the default checkpoint_completion_target=0.5. Here's a bigger patch, which does more. It is based on the ideas in the post I started this thread with, with feedback incorporated from the long discussion. With this patch, WAL disk space usage is controlled by two GUCs: min_recycle_wal_size checkpoint_wal_size These GUCs act as soft minimum and maximum on overall WAL size. At each checkpoint, the checkpointer removes enough old WAL files to keep pg_xlog usage below checkpoint_wal_size, and recycles enough new WAL files to reach min_recycle_wal_size. Between those limits, there is a self-tuning mechanism to recycle just enough WAL files to get to end of the next checkpoint without running out of preallocated WAL files. To estimate how many files are needed for that, a moving average of how much WAL is generated between checkpoints is calculated. The moving average is updated with fast-rise slow-decline behavior, to cater for peak rather than true average use to some extent. As today, checkpoints are triggered based on time or WAL usage, whichever comes first. WAL-based checkpoints are triggered based on the good old formula: CheckPointSegments = (checkpoint_max_wal_size / (2.0 + checkpoint_completion_target)) / 16MB. CheckPointSegments controls that like before, but it is now an internal variable derived from checkpoint_wal_size, not visible to users. These settings are fairly intuitive for a DBA to tune. You begin by figuring out how much disk space you can afford to spend on WAL, and set checkpoint_wal_size to that (with some safety margin, of course). Then you set checkpoint_timeout based on how long you're willing to wait for recovery to finish. Finally, if you have infrequent batch jobs that need a lot more WAL than the system otherwise needs, you can set min_recycle_wal_size to keep enough WAL preallocated for the spikes. You can also set min_recycle_wal_size = checkpoint_wal_size, which gets you the same behavior as without the patch, except that it's more intuitive to set it in terms of MB of WAL space required, instead of # of segments between checkpoints. Does that make sense? I'd love to hear feedback on how people setting up production databases would like to tune these things. The reason for the auto-tuning between the min and max is to be able to set reasonable defaults e.g for embedded systems that don't have a DBA to do tuning. Currently, it's very difficult to come up with a reasonable default value for checkpoint_segments which would work well for a wide range of systems. The PostgreSQL default of 3 is way way too low for most systems. On the other hand, if you set it to, say, 20, that's a lot of wasted space for a small database that's not updated much. With this patch, you can set max_wal_size=1GB and if the database ends up actually only needing 100 MB of
Re: [HACKERS] Redesigning checkpoint_segments
On 08/23/2013 02:08 PM, Heikki Linnakangas wrote: Here's a bigger patch, which does more. It is based on the ideas in the post I started this thread with, with feedback incorporated from the long discussion. With this patch, WAL disk space usage is controlled by two GUCs: min_recycle_wal_size checkpoint_wal_size snip These settings are fairly intuitive for a DBA to tune. You begin by figuring out how much disk space you can afford to spend on WAL, and set checkpoint_wal_size to that (with some safety margin, of course). Then you set checkpoint_timeout based on how long you're willing to wait for recovery to finish. Finally, if you have infrequent batch jobs that need a lot more WAL than the system otherwise needs, you can set min_recycle_wal_size to keep enough WAL preallocated for the spikes. We'll want to rename them to make it even *more* intuitive. But ... do I understand things correctly that checkpoint wouldn't kick in until you hit checkpoint_wal_size? If that's the case, isn't real disk space usage around 2X checkpoint_wal_size if spread checkpoint is set to 0.9? Or does checkpoint kick in sometime earlier? except that it's more intuitive to set it in terms of MB of WAL space required, instead of # of segments between checkpoints. Yes, it certainly is. We'll need to caution people that fractions of 16MB will be ignored. Does that make sense? I'd love to hear feedback on how people setting up production databases would like to tune these things. The reason for the auto-tuning between the min and max is to be able to set reasonable defaults e.g for embedded systems that don't have a DBA to do tuning. Currently, it's very difficult to come up with a reasonable default value for checkpoint_segments which would work well for a wide range of systems. The PostgreSQL default of 3 is way way too low for most systems. On the other hand, if you set it to, say, 20, that's a lot of wasted space for a small database that's not updated much. With this patch, you can set max_wal_size=1GB and if the database ends up actually only needing 100 MB of WAL, it will only use that much and not waste 900 MB for useless preallocated WAL files. This sounds good, aside from the potential 2X issue I mention above. Mind you, what admins really want is a hard limit on WAL size, so that they can create a partition and not worry about PG running out of WAL space. But ... Making it a hard limit is a much bigger task than I'm willing to tackle right now. ... agreed. And this approach could be built on for a hard limit later on. As a note, pgBench would be a terrible test for this patch; we really need something which creates uneven traffic. I'll see if I can devise something. -- Josh Berkus PostgreSQL Experts Inc. http://pgexperts.com -- 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
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 -- 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
Josh Berkus j...@agliodbs.com writes: On 08/23/2013 01:06 PM, Marko Tiikkaja wrote: Is there some reason we wouldn't use RETURN QUERY in that case, instead of SELECT? As I said above, it would be more consistent with existing PL/pgSQL. How would using the same syntax to do an entirely different thing be consistent? 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. 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. 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. 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] What happens at BIND time?
All, Per -performance, we're trying to isolate and reproduce a customer issue where on 9.2 BINDs get progressively slower (as much as 2000% slower) over the course of a long test run, in a way they *don't* in 8.4. So I'm looking for a cause for this. One thing would help is a clearer understanding of what happens at BIND time for 3-phase queries. Note that, in this workload, the user is re-parsing the queries over-and-over rather than using prepared plans properly. -- Josh Berkus PostgreSQL Experts Inc. http://pgexperts.com -- 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] What happens at BIND time?
Josh Berkus j...@agliodbs.com writes: So I'm looking for a cause for this. One thing would help is a clearer understanding of what happens at BIND time for 3-phase queries. Planning. Note that, in this workload, the user is re-parsing the queries over-and-over rather than using prepared plans properly. Does the backend's memory usage climb, or hold steady? If the former, I'd bet on client failure to release resources, eg not closing the portals when done with them. A memory map from MemoryContextStats would help determine exactly what's leaking. 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] Parallel pg_basebackup
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. -- 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] Reducing size of WAL record headers
On 1/10/13 6:14 PM, Simon Riggs wrote: On 10 January 2013 20:13, Tom Lane t...@sss.pgh.pa.us wrote: Bruce Momjian br...@momjian.us writes: On Wed, Jan 9, 2013 at 05:06:49PM -0500, Tom Lane wrote: Let's wait till we see where the logical rep stuff ends up before we worry about saving 4 bytes per WAL record. Well, we have wal_level to control the amount of WAL traffic. That's entirely irrelevant. The point here is that we'll need more bits to identify what any particular record is, unless we make a decision that we'll have physically separate streams for logical replication info, which doesn't sound terribly attractive; and in any case no such decision has been made yet, AFAIK. You were right to say that this is less important than logical replication. I don't need any more reason than that to stop talking about it. I have a patch for this, but as yet no way to submit it while at the same time saying put this at the back of the queue. Anything ever come of this? -- Jim C. Nasby, Data Architect j...@nasby.net 512.569.9461 (cell) http://jim.nasby.net -- 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] Hardware donation
On 6/22/13 8:19 AM, Simon Riggs wrote: On 21 June 2013 20:03, Jim Nasby j...@nasby.net wrote: Who can be point of contact from the community to arrange shipping, etc? Do they need to be shipped? Can we just leave them where they are and arrange access and power charges to be passed to SPI? Sounds like it would be cheaper and easier to leave them where they are and they won't get damaged in transit then. Of course, may not be possible. Sorry for the late reply, just saw this. Actually, we have the exact opposite problem... someone higher up the food chain than I am is strongly opposed to us hosting a server for the community in any of our data centers. We actually can pay for hosting somewhere if that's an issue. BTW, I also missed Mark's reply to this... I'll get in touch with him about shipping. -- Jim Nasby, Lead Data Architect (512) 569-9461 (primary) (512) 579-9024 (backup) -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
