On Sat, Sep 26, 2015 at 6:07 AM, Robert Haas wrote:
>
> On Fri, Sep 25, 2015 at 7:46 AM, Amit Kapila
wrote:
> > I have a question here which is why this format doesn't have a similar
> > problem
> > as the current version, basically in current patch the second read of
> > SerializedParamExternDat
Here is a v10, which is a rebase because of the "--progress-timestamp"
option addition.
It also include the fix for the tps without connection computation and
some minor code simplification, so it is redundant with this bug fix
patch:
https://commitfest.postgresql.org/7/378/
--
Fa
On Sat, Sep 26, 2015 at 5:52 AM, Robert Haas wrote:
>
> On Fri, Sep 25, 2015 at 12:00 AM, Amit Kapila
wrote:
> > I think initPlan will work with the existing patches as we are always
> > executing it in master and then sending the result to workers. Refer
> > below code in funnel patch:
>
> Sure,
On 2015-09-25 17:45, Alvaro Herrera wrote:
I think the API of getOpFamilyInfo is a bit odd; is the caller expected
to fill intype and keytype always, and then it only sets the procs/opers
lists? I wonder if it would be more sensible to have that routine
receive the pg_opclass tuple (or even the
On Sat, Sep 26, 2015 at 12:38 PM, Amit Kapila
wrote:
>
> On Sat, Sep 26, 2015 at 6:07 AM, Robert Haas
wrote:
> >
>
> > Assuming I'm not confused, I'm planning to see about fixing this...
> >
>
> Can't we just traverse the queryDesc->planstate tree and fetch/add
> all the instrument information if
On Sat, Sep 26, 2015 at 7:18 AM, Jeff Janes wrote:
> If I have "alter table foo alter COLUMN bar SET STATISTICS" in the line
> buffer,
> it tab completes to add " TO", which is not legal.
>
> The attached patch makes it not tab complete anything at all, which is at
> least not actively misleading.
Hi,
On 09/18/2015 03:46 AM, Kyotaro HORIGUCHI wrote:
Hello,
At Thu, 17 Sep 2015 17:40:27 +0200, Tomas Vondra wrote
in <55fadeeb.4000...@2ndquadrant.com>
Yes, this seems sane. I've been poking at this a bit too, and I came
to the same plan in general, except that I think it's better to build
On Fri, Sep 25, 2015 at 7:41 PM, Teodor Sigaev wrote:
> I'm OK about continuing work on amvalidate if we can build consuensus on
>> its design.
>> Could you give some feedback on amvalidate version of patch please?
>>
>> http://www.postgresql.org/message-id/capphfds8zywenz9vw6te5rzxbol1vu_wsw181v
On Sat, Sep 26, 2015 at 1:46 AM, Nikolay Shaplov wrote:
> В письме от 25 сентября 2015 20:59:29 пользователь Michael Paquier написал:
>> Thanks! I just had a short look at it:
>> - I am not convinced that it is worth declaring 3 versions of
>> tuple_data_split.
> How which of them should we leave?
Hello,
These are interesting runs.
In a situation in which small values are set in dirty_bytes and
dirty_backgound_bytes, a buffer is likely stored in the HD immediately
after the buffer is written in the kernel by the checkpointer. Thus, I
tried a quick hack to make the checkpointer invoke
On Sat, Sep 26, 2015 at 3:08 AM, Amit Kapila wrote:
>> memcpy() can cope with unaligned data; structure member assignment can't.
>
> So doesn't coping means, it anyways have to have to pay the performance
> penality to make it equivalent to aligned address access. Apart from that,
> today I had r
On Sat, Sep 26, 2015 at 4:29 AM, Paul Ramsey wrote:
> On Thu, Aug 20, 2015 at 6:01 PM, Michael Paquier wrote:
> src/backend/utils/adt/format_type.c
> +/*
> + * This version allows a nondefault typemod to be specified and fully
> qualified.
> + */
> +char *
> +format_type_with_typemod_qualified(Oid
On Wed, Sep 23, 2015 at 1:04 AM, Alvaro Herrera
wrote:
> Euler Taveira wrote:
> > On 17-09-2015 14:21, Michael Paquier wrote:
> > >pg_dump relies on attnum to define the column ordering, so one
> > >possibility would be to do things more consistently at backend level.
>
> We discussed this in som
On 2015-09-26 21:54:46 +0900, Michael Paquier wrote:
> On Wed, Sep 23, 2015 at 1:04 AM, Alvaro Herrera
> wrote:
> > We discussed this in some other thread, not long ago. I looked briefly
> > in the archives but couldn't find it. I think the conclusion was
> > something along the lines of "hmm, t
On Sat, Sep 26, 2015 at 8:38 AM, Robert Haas wrote:
>> QueryDesc's totaltime is for instrumentation information for plugin's
>> like pg_stat_statements and we need only the total buffer usage
>> of each worker to make it work as the other information is already
>> collected in master backend, so I
Hi,
On 09/26/2015 01:28 PM, Tomas Vondra wrote:
The patch does not change the check_index_only implementation - it
still needs to check the clauses, just like in v1 of the patch. To
make this re-check unnecessary, we'd have to stick the remaining
clauses somewhere, so that check_index_only can
Hi,
I pushed this to 9.5 and master, committing the xlog page magic bump
separately. To avoid using a magic value from master in 9.5 I bumped the
numbers by two in both branches.
Should this get a release note entry given that we're not (at least
immediately) backpatching this?
Greetings,
Andre
Andres Freund writes:
> Should this get a release note entry given that we're not (at least
> immediately) backpatching this?
I'll probably put something in when I update the release notes for beta1
(next week sometime); no real need to deal with it individually.
regards,
On Sun, Sep 6, 2015 at 9:35 PM, Thomas Munro
wrote:
> Running various contrived aggregate queries on a large low cardinality
> dataset in a small range (therefore frequently the same weight & size), I
> managed to measure a small improvement of up to a few percent with the
> attached patch. I als
On Sat, Sep 26, 2015 at 10:16 AM, Robert Haas wrote:
> On Sat, Sep 26, 2015 at 8:38 AM, Robert Haas wrote:
>>> QueryDesc's totaltime is for instrumentation information for plugin's
>>> like pg_stat_statements and we need only the total buffer usage
>>> of each worker to make it work as the other
On 9/23/15 3:41 PM, Stephen Frost wrote:
> The CREATE POLICY documentation discusses how lack of a WITH CHECK
> policy means the USING expression is used:
>
> """
> Policies can be applied for specific commands or for specific roles. The
> default for newly created policies is that they apply for
2015-09-25 19:13 GMT+02:00 Shulgin, Oleksandr
:
>
>
> Some problems:
>
> There is a potential problem with the limited total number of DSM
> segments: it is reserved in a way to only allow 2 per backend (on average)
> and 64 additional per server, so if you run with the new option enabled at
> all
22 matches
Mail list logo
