On 10.08.2019 5:12, Craig Ringer wrote:
On Fri, 9 Aug 2019 at 22:07, Konstantin Knizhnik
mailto:k.knizh...@postgrespro.ru>> wrote:
Ok, here it is: global_private_temp-1.patch
Fantastic.
I'll put that high on my queue.
I'd love to see something like this get in.
Doubly so if it brin
Hi Jim,
Its never too later, as nothing has been concluded about that survey ;o)
For information, I thought It would be possible to get a more stable
QueryId,
by hashing relation name or fully qualified names.
With the support of Julien Rouhaud, I tested with this kind of code:
case RTE
On Sat, Aug 10, 2019 at 1:20 AM Heikki Linnakangas wrote:
> Hmm. Wouldn't it be more straightforward to have the extra tupindex
> field at the end of the struct?
> The initial sorting phase would deal with SortTuples, and the merge
> phase would deal with MergeTuples. The same comparison routines
On Wed, Aug 7, 2019 at 08:56:18AM -0400, Sehrope Sarkuni wrote:
> On Mon, Aug 5, 2019 at 9:02 PM Bruce Momjian wrote:
> I was thinking the WAL would use the same key since the nonce is unique
> between the two. What value is there in using a different key?
> Never having to worry about
On 8/9/19 7:54 PM, Jeff Davis wrote:
> On Sat, 2019-08-10 at 00:17 +0300, Heikki Linnakangas wrote:
>> This is a multi-dimensional problem. "channel_binding=require" is
>> one
>> way to prevent MITM attacks, but sslmode=verify-ca is another. (Does
>> Kerberos also prevent MITM?) Or you might want
On Fri, Aug 9, 2019 at 10:54:51PM -0400, Bruce Momjian wrote:
> On Thu, Aug 8, 2019 at 10:17:53PM -0400, Sehrope Sarkuni wrote:
> > On Thu, Aug 8, 2019 at 2:16 PM Bruce Momjian wrote:
> >
> > On Wed, Aug 7, 2019 at 08:56:18AM -0400, Sehrope Sarkuni wrote:
> > > Simplest approach for de
On 10/08/2019 02:14, Peter Geoghegan wrote:
The easy part was removing SortTuple.tupindex itself -- it was fairly
natural to stash that in the slab allocation for each tape. I used the
aset.c trick of having a metadata "chunk" immediately prior to address
that represents the allocation proper --
On Sat, Aug 10, 2019 at 3:27 AM Jim Finnerty wrote:
>
> I missed this thread. I'd be happy to post the code for what we use as the
> stable query identifier, but we could definitely come up with a more
> efficient algorithm if we're willing to assume that the sql statements are
> the same if and
Hi
just rebase
Regards
Pavel
schema-variables-rebase-20190810.patch.gz
Description: application/gzip
