On Wed, May 16, 2018 at 11:31 PM, Robert Haas wrote:
> On Mon, Apr 16, 2018 at 7:35 AM, Ashutosh Bapat
> wrote:
>> It does fix the problem. But the patch as is interferes with the way
>> we handle tableoid currently. That can be seen from the regression
>> diffs that the patch causes. RIght now,
Hi, Thomas!
> 17 мая 2018 г., в 9:40, Thomas Munro
> написал(а):
>
> On Wed, Mar 7, 2018 at 7:50 PM, Andrey Borodin wrote:
>> Here's new version of GiST VACUUM patch set aimed at CF 2018-09.
>
> Hi Andrey,
>
> FYI Windows doesn't like this patch[1].
>
> + uint16_t flags;
>
> I think th
Hi, Ivan!
> 19 марта 2018 г., в 15:32, Andrey Borodin написал(а):
> I was looking into this patch mainly because I was reviewing other checksums
> patch in different thread. But the purpose of this patch seems viable for me.
> After looking into the patch I'd like to propose some editorializatio
On 2018/05/17 14:19, Amit Langote wrote:
> Looking at this for a bit, I wondered if this crash wouldn't have occurred
> if the "propagation" had also considered join relations in addition to
> simple relations. For example, if I changed inheritance_planner like the
> attached (not proposing that w
On Tue, Mar 27, 2018 at 9:23 AM, Rady, Doug wrote:
> pgbench11-ppoll-v12.patch
Hi Doug,
FYI this patch is trying and failing to use ppoll() on Windows:
https://ci.appveyor.com/project/postgresql-cfbot/postgresql/build/1.0.30
--
Thomas Munro
http://www.enterprisedb.com
On 2018/05/17 14:15, David Rowley wrote:
> On 10 May 2018 at 21:56, David Rowley wrote:
>> On 10 May 2018 at 17:42, Simon Riggs wrote:
>>> Patch is good.
>>>
>>> The cause of this oversight is the lack of comments to explain the
>>> original coding, so we need to correct that in this patch, pleas
On 2018/05/17 12:30, Etsuro Fujita wrote:
> (2018/05/17 1:16), Robert Haas wrote:
>> Was it just good luck that this ever worked at all? I mean:
>>
>> - if (rti< root->simple_rel_array_size&&
>> - root->simple_rel_array[rti] != NULL)
>> + if (rti< subroot->simple_rel_arr
2018-05-17 7:03 GMT+02:00 Charles Cui :
> Hi Aleksander,
>
>I have the requirements to return a bytea array for some functions in
> pg_thrift plugin.
> What I did was similar to the following,
>
> bytea** ret = palloc(len * sizeof(bytea*));
> for (int i = 0; i < len; i++) {
>// allocate sp
On 10 May 2018 at 21:56, David Rowley wrote:
> On 10 May 2018 at 17:42, Simon Riggs wrote:
>> Patch is good.
>>
>> The cause of this oversight is the lack of comments to explain the
>> original coding, so we need to correct that in this patch, please.
>
> Thanks for looking.
>
> Yeah, the comment
Hi Aleksander,
I have the requirements to return a bytea array for some functions in
pg_thrift plugin.
What I did was similar to the following,
bytea** ret = palloc(len * sizeof(bytea*));
for (int i = 0; i < len; i++) {
// allocate space
ret[i] = palloc(size);
// fill in ret[i]
...
On Wed, Mar 7, 2018 at 7:50 PM, Andrey Borodin wrote:
> Here's new version of GiST VACUUM patch set aimed at CF 2018-09.
Hi Andrey,
FYI Windows doesn't like this patch[1].
+ uint16_t flags;
I think that needs to be uint16?
[1] https://ci.appveyor.com/project/postgresql-cfbot/postgresql/bu
Hi,
Currently our customer uses PostgreSQL 9.6 and hits ECPG's bug during using
numeric data type by SQLDA.
I confirmed that this problem is occurred on master and 9.6 latest branch.
PROBLEM
---
When the integer part of numeric data type is "0", cancellation
On 17 May 2018 at 01:19, Robert Haas wrote:
> Hmm, that's actually not as bad as I thought. Thanks for the
> explanation. I think if I were going to try to improve things, I'd
> try to annotate the Append node with the name of the partitioned table
> that it's using for pruning in case #2 and ca
(2018/05/17 1:16), Robert Haas wrote:
On Fri, May 11, 2018 at 8:46 AM, Etsuro Fujita
wrote:
I added an assertion test to make_modifytable to match that in
create_modifytable_path. Attached is an updated version of the patch.
Committed.
Thanks you!
Was it just good luck that this ever wo
(2018/05/17 0:27), Robert Haas wrote:
On Tue, Mar 27, 2018 at 9:00 AM, Etsuro Fujita
wrote:
Attached is a patch for fixing this issue.
This no longer applies.
The patch has already been committed by you [1]. Thanks for committing!
Best regards,
Etsuro Fujita
[1]
https://git.postgresql.
On 2018/05/17 11:40, David Rowley wrote:
> On 17 May 2018 at 13:52, Amit Langote wrote:
>> Commit 499be013de6 used 'partition' where it really meant 'partitioned' in
>> a few places including in a variable name. For example, what almost all
>> places call 'partitioned_rels', make_partition_prunei
On 17 May 2018 at 13:52, Amit Langote wrote:
> Commit 499be013de6 used 'partition' where it really meant 'partitioned' in
> a few places including in a variable name. For example, what almost all
> places call 'partitioned_rels', make_partition_pruneinfo called
> 'partition_rels'.
>
> Attached a
On Thu, May 17, 2018 at 5:54 AM, Bruce Momjian wrote:
>
> Oh, sorry, changed to:
>
> Allow single-evaluation queries, e.g. WHERE
> clause aggregate queries, and functions in the target list to be
> parallelized (Amit Kapila, Robert Haas)
>
LGTM. Thanks.
--
With Regards
On 2018-05-16 22:11:22 -0400, Tom Lane wrote:
> David Rowley writes:
> > On 17 May 2018 at 11:00, Andres Freund wrote:
> >> Wonder if we shouldn't just cache an estimated relation size in the
> >> relcache entry till then. For planning purposes we don't need to be
> >> accurate, and usually activ
David Rowley writes:
> On 17 May 2018 at 11:00, Andres Freund wrote:
>> Wonder if we shouldn't just cache an estimated relation size in the
>> relcache entry till then. For planning purposes we don't need to be
>> accurate, and usually activity that drastically expands relation size
>> will trigg
Hi.
Commit 499be013de6 used 'partition' where it really meant 'partitioned' in
a few places including in a variable name. For example, what almost all
places call 'partitioned_rels', make_partition_pruneinfo called
'partition_rels'.
Attached a patch to make that uniform to avoid confusion.
Than
On 17 May 2018 at 13:17, Amit Langote wrote:
> Or maybe, change the comment to say that even the negative indexes are
> 0-based like you pointed out, *but* instead of updating the comment like
> you suggest above, change the other index value assignment statement to
> not subtract 1 from the list_
On 17 May 2018 at 11:00, Andres Freund wrote:
> Wonder if we shouldn't just cache an estimated relation size in the
> relcache entry till then. For planning purposes we don't need to be
> accurate, and usually activity that drastically expands relation size
> will trigger relcache activity before
On 17 May 2018 at 10:55, Tom Lane wrote:
> David Rowley writes:
>> There's probably some argument for delaying obtaining the relation
>> size until after join removal and probably partition pruning too, but
>> it's currently done well before that in build_simple_rel, where the
>> RelOptInfo is bu
On 2018/05/17 3:28, David Rowley wrote:
> On 17 May 2018 at 02:51, Robert Haas wrote:
>> I think that's clearer. Committed with a few tweaks that are
>> hopefully improvements.
>
> Thanks for committing. Although, I disagree with your tweak:
>
> +* 1-based index into the *pds list.
>
> I t
On Thu, May 17, 2018 at 09:56:49AM +0900, Michael Paquier wrote:
> On Wed, May 16, 2018 at 08:20:49PM -0400, Bruce Momjian wrote:
> > SCRAM-with-binding is the first password method that attempts to avoid
> > man-in-the-middle attacks, and therefore is much less likely to be able
> > to trust what
On Wed, May 16, 2018 at 08:20:49PM -0400, Bruce Momjian wrote:
> SCRAM-with-binding is the first password method that attempts to avoid
> man-in-the-middle attacks, and therefore is much less likely to be able
> to trust what the endpoints supports. I think it is really the
> channel_binding_mode
On Wed, May 16, 2018 at 03:37:18PM -0400, Robert Haas wrote:
> On Wed, May 16, 2018 at 3:29 PM, Tom Lane wrote:
> > BTW, we seem to have some confusion here already:
> >
> > regression=# create function foo(int) returns int as 'select $1' language
> > sql;
> > CREATE FUNCTION
> > regression=# cre
On Wed, May 16, 2018 at 10:08:18AM -0400, Alvaro Herrera wrote:
> On 2018-May-15, Bruce Momjian wrote:
>
> > On Wed, May 16, 2018 at 09:01:35AM +0900, Tatsuo Ishii wrote:
> > > There's a small typo.
> > >
> > > > Add support for with huge(large) pages on Windows (Takayuki Tsunakawa,
> > > > Thom
On Wed, May 16, 2018 at 01:50:04PM +0300, Heikki Linnakangas wrote:
> >* Allow bytes to be specified for server variable sizes (Beena Emerson)
> >
> >The specification is "B".
>
> I had to dig the commit in the git history to figure out what this is. I'd
> suggest rewording this:
>
> * Allow serv
On Wed, May 16, 2018 at 09:55:05AM +0530, Amit Kapila wrote:
> On Wed, May 16, 2018 at 12:17 AM, Bruce Momjian wrote:
> > On Tue, May 15, 2018 at 08:45:07AM +0530, Amit Kapila wrote:
> >> No, it is not like that. We divide the scan among workers and each
> >> worker should perform projection of t
On Wed, May 16, 2018 at 08:59:23PM +0900, Michael Paquier wrote:
> On Wed, May 16, 2018 at 01:09:07PM +0300, Heikki Linnakangas wrote:
> > I have to agree with Bruce, that it's pretty useless to implement channel
> > binding, if there is no way to require it in libpq. IMHO that must be
> > fixed.
>
On Wed, May 16, 2018 at 01:22:45PM +0900, Michael Paquier wrote:
> On Mon, May 14, 2018 at 08:45:44PM -0400, Bruce Momjian wrote:
> > What TLS does is to mix the offered ciphers into the negotiation hash so
> > a man-in-the-middle can't pretend it doesn't support something. Could
> > we do somethi
On 2018-05-16 18:55:41 -0400, Tom Lane wrote:
> David Rowley writes:
> > On 17 May 2018 at 10:13, Tom Lane wrote:
> >> Yeah. It'd have to be a very heuristic thing that doesn't account
> >> for much beyond the number of relations in the query, and maybe their
> >> sizes --- although I don't thin
David Rowley writes:
> On 17 May 2018 at 10:13, Tom Lane wrote:
>> Yeah. It'd have to be a very heuristic thing that doesn't account
>> for much beyond the number of relations in the query, and maybe their
>> sizes --- although I don't think we even know the latter at the
>> point where join rem
On 17 May 2018 at 10:37, Tom Lane wrote:
> Thomas Munro writes:
>> IIUC in DB2 (the clear winner at join elimination in the article you
>> mentioned), you get these sorts of things by default (optimisation
>> level 5 includes it), but not if you SET CURRENT QUERY OPTIMIZATION =
>> 3 as many artic
On 2018-05-16 18:37:11 -0400, Tom Lane wrote:
> Thomas Munro writes:
> > IIUC in DB2 (the clear winner at join elimination in the article you
> > mentioned), you get these sorts of things by default (optimisation
> > level 5 includes it), but not if you SET CURRENT QUERY OPTIMIZATION =
> > 3 as ma
Thomas Munro writes:
> IIUC in DB2 (the clear winner at join elimination in the article you
> mentioned), you get these sorts of things by default (optimisation
> level 5 includes it), but not if you SET CURRENT QUERY OPTIMIZATION =
> 3 as many articles recommend for OLTP work. I think it's inter
On 16 May 2018 at 14:44, Tom Lane wrote:
> Dean Rasheed writes:
>> In the case 1 ^ NaN = 1, what should the result scale be?
>
> The result is exact, so I don't see a reason to be worried about its
> scale. Messing with the scale would also require expending even
> more code on what is, in the e
On 17 May 2018 at 10:13, Tom Lane wrote:
> Yeah. It'd have to be a very heuristic thing that doesn't account
> for much beyond the number of relations in the query, and maybe their
> sizes --- although I don't think we even know the latter at the
> point where join removal would be desirable. (A
On Wed, May 16, 2018 at 4:54 PM, Tom Lane wrote:
> Alexander Korotkov writes:
> > On Wed, May 16, 2018 at 1:41 AM, Tom Lane wrote:
> >> Perhaps there is a case for adding an additional flag to allow
> specifying
> >> "I can't support ORDER BY DESC", but I'm not in a big hurry to do so.
> >> I t
David Rowley writes:
> On 17 May 2018 at 08:44, Simon Riggs wrote:
>> What I was advocating was an approach that varies according to the
>> query cost, so we don't waste time trying to tune the heck out of OLTP
>> queries, but for larger queries we might take a more considered
>> approach.
> Tha
HI,
On 2018-05-17 08:48:58 +1200, David Rowley wrote:
> On 17 May 2018 at 08:44, Simon Riggs wrote:
> > What I was advocating was an approach that varies according to the
> > query cost, so we don't waste time trying to tune the heck out of OLTP
> > queries, but for larger queries we might take a
On Wed, May 16, 2018 at 10:41 PM, Andres Freund wrote:
> On 2018-05-16 15:49:29 +0300, Heikki Linnakangas wrote:
> > Here's a pretty straightforward fix for these two issues. Any objections
> or
> > better ideas?
>
> Generally ok, two minor points:
>
> > diff --git a/src/backend/utils/misc/guc.c
On 16 May 2018 at 09:55, Tom Lane wrote:
> David Rowley writes:
>> On 16 May 2018 at 02:01, Tom Lane wrote:
>>> I'm not particularly fussed about getting credit for that. However,
>>> looking again at how that patch series turned out --- ie, that
>>> we ensured POSIX behavior for NaNs only in H
On Thu, May 17, 2018 at 3:43 AM, Alexander Kuzmenkov
wrote:
> There is a join optimization we don't do -- removing inner join of a table
> with itself on a unique column. Such joins are generated by various ORMs, so
> from time to time our customers ask us to look into this. Most recently, it
> wa
David,
Many thanks for the detailed explanation. I'll try to code it up and
measure how much overhead it introduces.
--
Alexander Kuzmenkov
Postgres Professional: http://www.postgrespro.com
The Russian Postgres Company
On 17 May 2018 at 08:44, Simon Riggs wrote:
> What I was advocating was an approach that varies according to the
> query cost, so we don't waste time trying to tune the heck out of OLTP
> queries, but for larger queries we might take a more considered
> approach.
That's tricky. If we do this, it
On 17 May 2018 at 03:43, Alexander Kuzmenkov wrote:
> I'd be glad to hear your thoughts on this.
(I only glanced at the patch)
I've thought and discussed this before on this list. I think the
arguments for and against it were much the same as you've received
already. If you trawl through the arc
On 16 May 2018 at 15:10, Tom Lane wrote:
> Simon Riggs writes:
>> What I would add is that I've seen cases where the extra joins do NOT
>> hurt performance, so the extra CPU used to remove the join hurts more
>> than the benefit of removing it. Yes, we tried it.
>
> Interesting. The concern I ha
On Wed, May 16, 2018 at 09:33:46AM -0400, Robert Haas wrote:
> > In sum, I think the problem is mostly solved. Backend 2 unpins the
> > segment in next ts_lexize() call. But if backend 2 doesn't call
> > ts_lexize() (or other TS function) anymore the segment will remain mapped.
> > It is the only p
> On May 16, 2018, at 1:58 PM, Andres Freund wrote:
>
> Hi,
>
> On 2018-05-16 12:26:48 -0400, Robert Haas wrote:
>> Also, I'm not sure that I believe that it's always easy to avoid
>> generating such queries.
>
> Yea. There's obviously plenty cases where ORMs just want to make the
> database h
Simon Riggs writes:
> What I would add is that I've seen cases where the extra joins do NOT
> hurt performance, so the extra CPU used to remove the join hurts more
> than the benefit of removing it. Yes, we tried it.
Interesting. The concern I had was more about the cost imposed on every
query t
On 16 May 2018 at 11:26, Robert Haas wrote:
> On Wed, May 16, 2018 at 12:08 PM, Tom Lane wrote:
>> Alexander Kuzmenkov writes:
>>> There is a join optimization we don't do -- removing inner join of a
>>> table with itself on a unique column. Such joins are generated by
>>> various ORMs, so from
Hi,
On 2018-05-16 15:49:29 +0300, Heikki Linnakangas wrote:
> Here's a pretty straightforward fix for these two issues. Any objections or
> better ideas?
Generally ok, two minor points:
> diff --git a/src/backend/utils/misc/guc.c b/src/backend/utils/misc/guc.c
> index 7cd2d2d80e..93402030f7 1006
On Wed, May 16, 2018 at 3:29 PM, Tom Lane wrote:
> My opinion remains unchanged. If you're unhappy about the system
> confusing procedure foo(int) and function foo(real), maybe the answer
> is to not overload the name "foo" with such enthusiasm. But putting
> kluges into (some of) the lookup rul
Robert Haas writes:
> On Fri, Mar 23, 2018 at 10:42 AM, Ashutosh Bapat
> wrote:
>> On Fri, Mar 23, 2018 at 7:53 PM, Tom Lane wrote:
>>> ISTM this patch effectively proposes to make procedures have their own
>>> namespace yet still live in pg_proc. That is the worst of all possible
>>> worlds IM
On Wed, May 16, 2018 at 2:28 PM, David Rowley
wrote:
> Thanks for committing. Although, I disagree with your tweak:
>
> +* 1-based index into the *pds list.
>
> I think that's making the same mistake as the last comment did. You
> think it's 1-based because the index is being set with list_len
On Fri, Mar 23, 2018 at 10:42 AM, Ashutosh Bapat
wrote:
> On Fri, Mar 23, 2018 at 7:53 PM, Tom Lane wrote:
>> Ashutosh Bapat writes:
>>> Incidently the fix looks quite simple. See patch attached.
>>
>> ISTM this patch effectively proposes to make procedures have their own
>> namespace yet still
Hi,
On 2018-05-16 12:26:48 -0400, Robert Haas wrote:
> Also, I'm not sure that I believe that it's always easy to avoid
> generating such queries.
Yea. There's obviously plenty cases where ORMs just want to make the
database hurt. But especially when building a join between a number of
tables bas
On 17 May 2018 at 02:51, Robert Haas wrote:
> On Mon, May 14, 2018 at 12:57 AM, David Rowley
> wrote:
>> The "minus 1" part is incorrect. It simply just stores the 0-based
>> index of the item in the list. I was going to fix it by removing just
>> that part, but instead, I ended up rewriting the
On Mon, Apr 16, 2018 at 7:35 AM, Ashutosh Bapat
wrote:
> It does fix the problem. But the patch as is interferes with the way
> we handle tableoid currently. That can be seen from the regression
> diffs that the patch causes. RIght now, every tableoid reference gets
> converted into the tableoid
On 14/05/18 02:15, Thomas Munro wrote:
Hello,
Since commit cdf91edb (2012), nodeIndexonlyscan.c says:
/*
* Predicate locks for index-only scans must be
acquired at the page
* level when the heap is not accessed, since
tuple-level predicate
On 16/05/18 16:35, Alexander Korotkov wrote:
I also think it would be nice to show units in the valid range. I image
that if I would see such message at the first time, then I would try to
reverse-engineer units from input value representation in the error
message. Displaying units in the valid
On Wed, May 16, 2018 at 11:28 AM, Tom Lane wrote:
> Robert Haas writes:
>> On Tue, May 15, 2018 at 4:46 AM, Ideriha, Takeshi
>> wrote:
>>> I noticed that if log_min_messages is set to ‘debug2’, it shows ‘debug’
>>> instead of debug2.
>
>> Seems worth changing to me. Anyone else think differentl
On Wed, May 16, 2018 at 6:24 PM, Alvaro Herrera
wrote:
> On 2018-May-16, Magnus Hagander wrote:
>
> > On Wed, May 16, 2018 at 4:08 PM, Alvaro Herrera <
> alvhe...@2ndquadrant.com>
> > wrote:
>
> > > I'm not sure why we say "huge (large) pages". The natural term for
> > > Windows is "large-pages"
On Wed, May 16, 2018 at 12:08 PM, Tom Lane wrote:
> Alexander Kuzmenkov writes:
>> There is a join optimization we don't do -- removing inner join of a
>> table with itself on a unique column. Such joins are generated by
>> various ORMs, so from time to time our customers ask us to look into
>> t
On 2018-May-16, Magnus Hagander wrote:
> On Wed, May 16, 2018 at 4:08 PM, Alvaro Herrera
> wrote:
> > I'm not sure why we say "huge (large) pages". The natural term for
> > Windows is "large-pages",
> > https://msdn.microsoft.com/en-us/library/windows/desktop/
> > aa366720(v=vs.85).aspx
> > so
On Wed, May 16, 2018 at 4:08 PM, Alvaro Herrera
wrote:
> On 2018-May-15, Bruce Momjian wrote:
>
> > On Wed, May 16, 2018 at 09:01:35AM +0900, Tatsuo Ishii wrote:
> > > There's a small typo.
> > >
> > > > Add support for with huge(large) pages on Windows (Takayuki
> Tsunakawa, Thomas Munro)
> > >
On Fri, May 11, 2018 at 8:46 AM, Etsuro Fujita
wrote:
> I added an assertion test to make_modifytable to match that in
> create_modifytable_path. Attached is an updated version of the patch.
Committed. Was it just good luck that this ever worked at all? I mean:
-if (rti < root->simple
Alexander Kuzmenkov writes:
> There is a join optimization we don't do -- removing inner join of a
> table with itself on a unique column. Such joins are generated by
> various ORMs, so from time to time our customers ask us to look into
> this. Most recently, it was discussed on the list in re
On 16.05.2018 18:09, Grigory Smolkin wrote:
Hello!
I have noticed that psql --help lack -Z|--compression option.
Also it would be nice to have option like --compression-level in psql
and pgbench.
Thank you for this notice.
Updated and rebased patch is attached.
Concerning specification of
Hi hackers,
There is a join optimization we don't do -- removing inner join of a
table with itself on a unique column. Such joins are generated by
various ORMs, so from time to time our customers ask us to look into
this. Most recently, it was discussed on the list in relation to an
article c
On 16 May 2018 16:50:24 EEST, Hubert Zhang wrote:
>There are remaining two problems
>
>1. Do we need to consider when to delete the extension hook or it's not
>necessary?
No, PostgreSQL never unloads shared libraries, so that can be ignored.
We used to, and that's what _PG_fini() was for. But
Robert Haas writes:
> On Tue, May 15, 2018 at 4:46 AM, Ideriha, Takeshi
> wrote:
>> I noticed that if log_min_messages is set to ‘debug2’, it shows ‘debug’
>> instead of debug2.
> Seems worth changing to me. Anyone else think differently?
I think the current behavior was intentional at some po
On Tue, Mar 27, 2018 at 9:00 AM, Etsuro Fujita
wrote:
> Attached is a patch for fixing this issue.
This no longer applies.
--
Robert Haas
EnterpriseDB: http://www.enterprisedb.com
The Enterprise PostgreSQL Company
On Tue, May 15, 2018 at 12:06 PM, Tom Lane wrote:
>> One can imagine extensions of the idea: for example, the header could
>> actually be used to identify the columns, so the column order in the file
>> doesn't matter. There could also be an "AS" syntax to allow the target
>> field names to be dif
Hello!
I have noticed that psql --help lack -Z|--compression option.
Also it would be nice to have option like --compression-level in psql
and pgbench.
On 03/30/2018 03:53 PM, Konstantin Knizhnik wrote:
Hi hackers,
One of our customers was managed to improve speed about 10 times by
using SS
David Rowley writes:
> On 16 May 2018 at 11:04, Tom Lane wrote:
>> No, it should go under "planner improvement". If this were a bug fix,
>> it'd be a candidate for back-patch, which IMO it's not --- if only
>> because of the risk of plan destabilization.
> I'm not going to make a fuss over it,
On Tue, May 15, 2018 at 4:46 AM, Ideriha, Takeshi
wrote:
> I noticed that if log_min_messages is set to ‘debug2’, it shows ‘debug’
> instead of debug2.
>
> Patch attached.
Seems worth changing to me. Anyone else think differently?
--
Robert Haas
EnterpriseDB: http://www.enterprisedb.com
The En
On Mon, May 14, 2018 at 12:57 AM, David Rowley
wrote:
> I noticed that a comment in get_partition_dispatch_recurse claims that:
>
> "it contains the
> * leaf partition's position in the global list *leaf_part_oids minus 1"
>
> The "minus 1" part is incorrect. It simply just stores the 0-based
> in
> I think you are trying collecting data from multple kafka
> server. This means each server has a dedicate foreign table on a
> dedicate foreign server. Parallel execution doesn't fit in that
> case since it works on single base relation (or a
> table). Parallel append/merge append look a bit dif
Teodor Sigaev writes:
> Thank you. Seems, it works, at least I can't find a counter-example for that.
Will push, thanks for reviewing.
regards, tom lane
On 2018-May-15, Bruce Momjian wrote:
> On Wed, May 16, 2018 at 09:01:35AM +0900, Tatsuo Ishii wrote:
> > There's a small typo.
> >
> > > Add support for with huge(large) pages on Windows (Takayuki Tsunakawa,
> > > Thomas Munro)
> >
> > I think a space between "huge" and "(large)" is needed.
>
Thank you. Seems, it works, at least I can't find a counter-example for that.
Tom Lane wrote:
Teodor Sigaev writes:
I'm not understand why postgres prefers to sort table instead of using
index only scan when query is a simple inner join on composite type.
Query with equality clause with consta
Alexander Korotkov writes:
> On Wed, May 16, 2018 at 1:41 AM, Tom Lane wrote:
>> Perhaps there is a case for adding an additional flag to allow specifying
>> "I can't support ORDER BY DESC", but I'm not in a big hurry to do so.
>> I think there would be more changes than this needed to handle suc
There are remaining two problems
1. Do we need to consider when to delete the extension hook or it's not
necessary?
As the destroy function _PG_fini doesn't work, I cannot find a good
place to reset to hook gracefully.
I tested the drop language plpythonu statement which will not remove
th
On Wed, May 16, 2018 at 4:01 PM, Etsuro Fujita
wrote:
>
So we could
really minimize the code change and avoid the additional overhead caused
by
the is_converted_whole_row_reference test added to pull_var_clause. I
think
the latter would be rather important, because P
Dean Rasheed writes:
> On 15 May 2018 at 22:55, Tom Lane wrote:
>> Here's a proposed patch for that.
> In the case 1 ^ NaN = 1, what should the result scale be?
The result is exact, so I don't see a reason to be worried about its
scale. Messing with the scale would also require expending even
On Wed, May 16, 2018 at 3:49 PM, Heikki Linnakangas wrote:
> On 16/05/18 15:19, Heikki Linnakangas wrote:
>
>> $ postmaster -c track_activity_query_size=1024TB
>> FATAL: invalid value for parameter "track_activity_query_size": "1024TB"
>> HINT: Valid units for this parameter are "kB", "MB", "GB
Hi!
On Wed, May 16, 2018 at 3:19 PM, Heikki Linnakangas wrote:
> I played around with the GUC memory units, specifically to test the new
> GUC_UNIT_BYTES flag (commit 6e7baa32):
>
> $ postmaster -c track_activity_query_size=1024kB
> FATAL: 1048576 is outside the valid range for parameter
> "tra
On Wed, May 16, 2018 at 7:36 AM, Arthur Zakirov
wrote:
>> I don't quite understand the problem you're trying to solve here, but:
>>
>> 1. Unless dsm_pin_segment() is called, a DSM segment will
>> automatically be removed when there are no remaining mappings.
>>
>> 2. Unless dsm_pin_mapping() is ca
On Thu, May 10, 2018 at 10:22 PM, David Rowley
wrote:
> Here's a recap of the current way to determine where the pruning occurred:
>
> Phase 1: Plan time pruning:
>
> EXPLAIN/EXPLAIN ANALYZE shows Append/MergeAppend/ModifyTable shows
> fewer subnodes than there are partitions.
> Both EXPLAIN and E
On Tue, May 15, 2018 at 6:07 PM, Tom Lane wrote:
> That seems like an awful lot of work to handle what's still going to be
> a pretty small set of permissions. Every permission we add is going to
> have to be enforced in the C code, and it'll break applications to some
> extent to treat the situa
On 16/05/18 15:19, Heikki Linnakangas wrote:
$ postmaster -c track_activity_query_size=1024TB
FATAL: invalid value for parameter "track_activity_query_size": "1024TB"
HINT: Valid units for this parameter are "kB", "MB", "GB", and "TB".
...
The HINT in the last message seems wrong: the hint cl
Hi,
I played around with the GUC memory units, specifically to test the new
GUC_UNIT_BYTES flag (commit 6e7baa32):
$ postmaster -c track_activity_query_size=1024kB
FATAL: 1048576 is outside the valid range for parameter
"track_activity_query_size" (100 .. 102400)
$ postmaster -c track_acti
> On 15 May 2018, at 15:53, Robert Haas wrote:
>
> Actually, I think if we're going to pursue that approach, we ought to
> back off a bit from thinking about global snapshots and think about
> what kind of general mechanism we want. For example, maybe you can
> imagine it like a message bus, w
On Wed, May 16, 2018 at 01:09:07PM +0300, Heikki Linnakangas wrote:
> I have to agree with Bruce, that it's pretty useless to implement channel
> binding, if there is no way to require it in libpq. IMHO that must be
> fixed.
Wouldn't we want to also do something for the case where a client is
will
Hello,
On Tue, May 15, 2018 at 05:02:43PM -0400, Robert Haas wrote:
> On Tue, Mar 27, 2018 at 8:19 AM, Arthur Zakirov
> wrote:
> > Yes, there is dsm_pin_mapping() for this. But it is necessary to keep a
> > segment even if there are no attached processes. From 0003:
> >
> > + /* Remain atta
* Allow bytes to be specified for server variable sizes (Beena Emerson)
The specification is "B".
I had to dig the commit in the git history to figure out what this is.
I'd suggest rewording this:
* Allow server options related to memory and file sizes, to be specified
as number of bytes.
1 - 100 of 111 matches
Mail list logo
