All,
I have reviewed and tested these patches.
The patches applied cleanly in order against master at (90947674fc).
I ran the provided regression tests and a 'check-world'. All tests succeeded.
Marking ready for committer.
-Adam
>> If a new unlogged relation is created after constructed the
>> unloggedHash before sending file, we cannot exclude such relation. It
>> would not be problem if the taking backup is not long because the new
>> unlogged relation unlikely becomes so large. However, if takeing a
>> backup takes a lo
> I agree with #1 and feel the updated docs are reasonable and
> sufficient to address this case for now.
>
> I have retested these patches against master at d6ab720360.
>
> All test succeed.
>
> Marking "Ready for Committer".
Actually, marked it "Ready for Review" to wait for Masahiko to comment/
On Mon, Jan 29, 2018 at 1:17 PM, David Steele wrote:
> On 1/29/18 9:13 AM, David Steele wrote:
>> On 1/29/18 5:28 AM, Masahiko Sawada wrote:
>>> But I
>>> have a question; can we exclude temp tables as well? The pg_basebackup
>>> includes even temp tables. But I don't think that it's necessary for
All,
> So, context:
>
> - We want PostGIS to parallelize more. In order to achieve that we need to
> mark our functions with more realistic COSTs. Much much higher COSTs.
> - When we do that, we hit a different problem. Our most commonly used
> functions, ST_Intersects(), ST_DWithin() are actual
>> > * Solution #2 - Quick and dirty and invisible. Tom suggested a hack that
>> > achieves the aims of #1 but without adding syntax to CREATE FUNCTION: have
>> > the inlining logic look at the cost of the wrapper and the cost of
>> > parameters, and if the cost of the wrapper "greatly exceeded"
