wal_keep_size (new in v.13) parameter specifies the minimum size of past log file segments kept in the pg_wal directory. How to set an appropriate value for this parameter?
It is not really new. Before v13, it was called wal_keep_segments. It was counted in different units, but did the same thing. But generally you should be using slots instead. If you do need to use wal_keep_size rather than slots for some reason, then that reason (unknown to us) should determine what to set it to.
Related
It is a common fact that it is better in a certain circumstances to pass a parameter by reference to avoid costly copying. But recently I watched a Handmade Hero series where Casey said that if the object is not too complex sometimes it's better to pass it by value. I'm not too familiar with low-level details, but I assume it's connected with a cache. Could someone give more solid explanation of what's going on?
If you pass by value you are likely passing via registers (assuming not too many arguments and each one is not too large). That means the callee doesn't need to do anything to use the values, they are already in registers. If passing by reference, the address of each value may be in a register, but that requires a dereference which needs to look in the CPU cache (if not main memory), which is slower.
On many popular systems you can pass-by-value roughly 5-10 values which are each as wide as an address.
I have beeen constructing a model in Anylogic in the last weeks, and I am currently simulating the time a truck takes to deliver its products, so I used a delay for this in which different parameters are multiplied to several distributions. Is there any was I can keep track of the value of the distribution each time the process takes place. The following is in example:
normal(2, 8, 4.67, 1.96)*DropSize
The DropSize is my parameter, but I wish to know what value was generated for the normal distribution, and keep track of this.
Sure, several ways (as usual with AnyLogic :-) ). Here is one:
create a collection of type ArrayList:
Then, create a function that draws the random value, stores it in the collection and returns it as below:
Last, replace your code creating the random value with calling that function. Now, whenever you pull a value from the distribution, it is also stored in the collection.
cheers
What I understand is, that GameplayAbilities do not need to replicate to update GameplayAttributes across the network, since they don't influence attributes directly. Instead, this is the task of GameplayEffects.
So what is it that updates the GameplayAbilitySystem attribute values (FGameplayAttributeData) over the network:
do only attributes replicate?
or are the GameplayEffects sent only?
or both?
To give context: I have an attribute modification system where I need several “base values”. Those “base values” change very infrequently, while the “final value” changes often. There are two possibilities to do that with GAS
use a separate attribute for each of the “base values” and “final value” or
add additional float members to the attribute struct FGameplayAttributeData, for all “base values” and the “final value”
If only GE are sent over the network (and not attributes), I would go for (2), since the size of an attribute doesn't matter for bandwidth then.
Both are replicated!
GameplayAttributes are replicated with an OnRep function, which calls FActiveGameplayEffectsContainer::SetBaseAttributeValueFromReplication(), which - despite the name - will also updates the current value using the aggregators which are existing on the local machine. For that to work, also ...
GameplayEffects replicate (see also Unreal GAS: GameplayEffect: Difference between minimal and full replication).
So for saving bandwidth in the example given, it is more meaningful to use separate attributes for the “base values” (option (1)), since they are not updated very often. So when the “final value” changes, the constant “base values” won’t have to be replicated.
I recall when doing an ftp get to copy files from mainframe to windows that there would always be some numeric suffix on the filenames that would change each day. ie abc.4328 then it would become abc.23595..etc what is the concept/terminology of the changing suffix in mainframe world?
Leaving aside mainframe files residing in the Unix file system (z/OS is a flavor of Unix and has been for some years now), mainframe files do not have an extension or suffix.
Mainframe file names (called DataSet Names or DSNs) take the form HLQ[.Q1[.Q2[.Qn]]] where HLQ is the High Level Qualifier and Q1...Qn are subsequent qualifiers separated from the HLQ and each other by full-stops. The entire DSN must be no more than 44 characters. Each qualifier must be comprised of alphabetic, numeric, and what IBM calls "national" characters which (in the USA anyway) are #, # and $. Additionally, a qualifier may not begin with a numeric character. There are exceptions to this which, in my opinion, are best avoided.
As Bruce Martin indicates in his comment, mainframes have the concept of Generation Data Groups (GDGs) which have a lowest level qualifier taking the form GnnnnVnn generated by the operating system where the four digits between the G and V are the "generation number" and the two digits following the V are the "version number." The generation number is incremented by the operating system each time a new instance of the file is created.
So it is possible you are thinking of a GDG. Be advised that the GDG lowest level qualifier is not dependent on date or time, it merely indicates the order in which the instances of the dataset were created.
GDGs are normally accessed not by absolute generation number but by relative generation number. If ABC.DEF is a GDG and there are four extant generations ABC.DEF.G0008V00, ABC.DEF.G0009V00, ABC.DEF.G0010V00, ABC.DEF.G0011V00 then a reference to ABC.DEF(0) would be shorthand for ABC.DEF.G0011V00. A reference to ABC.DEF(-1) would be shorthand for ABC.DEF.G0010V00. Referencing relative generation (0) is always a reference to the most recently created instance of the GDG.
A mainframe dataset may also be a PDS (Partitioned DataSet). Partitioned datasets have "members" and are conceptually slightly similar to (though implemented very differently from) directories on PC or Unix file systems. A PDS may contain many related members, such as utility control statements, where there is a desire to manage them as a group.
PDS names follow the same rules as normal DSNs, and member names follow the same rules as normal DSN qualifiers, but referring to a member requires specifying it in parentheses. If MY.DATA is a PDS and I wish to access a member whose name is XYZ I would specify MY.DATA(XYZ).
Note that the format of a dataset is not necessarily indicated in its name. That a dataset is, e.g. a PDS containing fixed 100 byte records is recorded as metadata in the file system.
Great response from #cschneid above. To add to it:
There's doc from IBM on GDGs on the z/OS Basic Skills page - https://www.ibm.com/support/knowledgecenter/zosbasics/com.ibm.zos.zconcepts/zconcepts_175.htm
There are several dataset types - a GDG isn't really a different dataset organization, it's just a special naming convention that indicates relative "age". There are sequential datasets ("flat files"), partitioned datasets (sort of like a collection of flat files surrounded by a directory), VSAM datasets (a very long topic), and a few other esoteric types that aren't used much these days.
GDGs are a pretty slick way of naming (non-VSAM) datasets with version numbers that can be referenced in JCL or line commands using those relative version numbers. But it's just naming
Trivia: In places I've worked, systems programmers and operations staff members would often refer to those GnnnnVnn as "goovoo" numbers, b/c they often were numbered G00nnV00.. :-)
I'm composing several files into one and then i do perform a "rewrite" operation to reset componentsCount, so they won't block further compositions (to avoid 1024 components problem, actually). But, the resulting rewritten object's componentCount property increases as if it was just a "rename" request.
It is stated in documentation (https://cloud.google.com/storage/docs/json_api/v1/objects/rewrite):
When you rewrite a composite object where the source and destination
are different locations and/or storage classes, the result will be a
composite object containing a single component (and, as always with
composite objects, it will have only a crc32c checksum, not an MD5).
It is not clear to me what do they mean by "different locations" -- different object names and/or different buckets?
Is there a way to reset this count w/o downloading and uploading resulting composite?
Locations refers to geographically where the source and destination bucket are (us-east1, asia, etc.) -- see https://cloud.google.com/about/locations
If your rewrite request is between buckets in different locations and/or storage classes, the operation does byte copying and (in the case of composite objects) will result in a new object with component count 1. Otherwise the operation will complete without byte copying and in that case (in the case of composite objects) will not change the component count.
It's no longer necessary to reset the component count using rewrite or download/upload because there's no longer a restriction on the component count. Composing > 1024 parts is allowed.
https://cloud.google.com/storage/docs/composite-objects