On Fri, May 17, 2019 at 3:10 AM Alvaro Herrera
wrote:
> On 2019-May-14, Michael Paquier wrote:
>
> > On Tue, May 14, 2019 at 01:19:30PM +1200, David Rowley wrote:
> > > When I wrote the code I admit that I was probably wearing my
> > > object-orientated programming hat. I had in mind that the
Agree that this behavior change seems unintentional.
On 2019/05/17 12:40, Rushabh Lathia wrote:
> Looking at the commit changes, it seems like at condition when no other
> tablespace is specified, we default the tablespace to the parent partitioned
> table's.
>
> else if (stmt->partbound)
>
Couple patches improving jsonpath docs are attached. The first one
documents nesting level filter for .** accessor. The second adds to
documentation of jsonpath array subsciption usage of expressions and
multiple slice ranges. I'm going to push both patches if no
objections.
--
Alexander
On Thu, May 16, 2019 at 2:03 PM Andres Freund wrote:
> Hi,
>
> On 2019-05-16 13:59:47 -0700, Melanie Plageman wrote:
> > On Wed, May 15, 2019 at 10:32 PM Ashwin Agrawal
> wrote:
> >
> > >
> > > The second index would help to hold the session after inserting the
> tuple
> > > in unique index but
Hi,
Consider the below test:
create tablespace mytbs location '/home/rushabh/mywork/workspace/pg/';
create table test ( a int , b int ) partition by list (a);
set default_tablespace to mytbs;
create table test_p1 partition of test for values in (1);
In the above test, after the setting the
Hi,
On 2019-05-08 13:06:36 +0900, Kyotaro HORIGUCHI wrote:
> This behavior is introduced by 69c3936a14 (in v11). At that time
> FunctionCallInfoData is pallioc0'ed and has fixed length members
> arg[6] and argnull[7]. So nulls[1] is always false even if nargs
> = 1 so the issue had not been
On Wed, May 15, 2019 at 03:44:22PM +0900, Masahiko Sawada wrote:
> I've attached new version patch that takes the way to let the backend
> parser do all work.
I was wondering how the error handling gets by not having the parsing
on the frontend, and it could be worse:
$ vacuumdb
On Thu, May 16, 2019 at 10:13:22PM +0500, Andrey Borodin wrote:
> Meanwhile I made some enhancements to test suit:
> Intel Server
> NOTICE: 0: Decompressor pglz_decompress_hacked result 10.346763
> NOTICE: 0: Decompressor pglz_decompress_hacked8 result 11.192078
> NOTICE: 0:
On Thu, May 9, 2019 at 10:23 PM Thomas Munro wrote:
> The reason the patch didn't solve the problem is that
> AtEOXact_Parallel() calls DestroyParallelContext(). So DSM segments
> that happen to belong to ParallelContext objects are already gone by
> the time resowner.c gets involved.
This was
On Thu, May 16, 2019 at 03:29:36PM -0400, Robert Haas wrote:
> I'm not sure how much value it really has to define
> opt_boolean_or_string_or_numeric. It saves 1 line of code in each of
> 3 places, but costs 6 lines of code to have it.
>
> Perhaps we could try to unify at a higher level. Like
Mmm. It has gone before complete.
At Fri, 17 May 2019 10:21:21 +0900 (Tokyo Standard Time), Kyotaro HORIGUCHI
wrote in
<20190517.102121.72558057.horiguchi.kyot...@lab.ntt.co.jp>
> We now have several syntax elements seemingly the same but behave
> different way.
>
> At Thu, 16 May 2019
We now have several syntax elements seemingly the same but behave
different way.
At Thu, 16 May 2019 15:29:36 -0400, Robert Haas wrote
in
> On Thu, May 16, 2019 at 2:56 PM Fujii Masao wrote:
> > Yes. Thanks for the comment!
> > Attached is the updated version of the patch.
> > It adds such
Hi!
On Tue, May 14, 2019 at 3:54 AM Andrew Alsup wrote:
> array slicing [0:], [:1], and [0:1] do not work:$.c1.c2[0:].b3
>
> # select json_path_query('{"a1": 123, "b1": "xxx", "c1": {"a2": 456,
> "b2": "yyy", "c2": [{"a3": 777, "b3": "7z"},{"a3": 888, "b3":
> "8z"}]}}'::json,
On Fri, May 17, 2019 at 11:46 AM Tomas Vondra
wrote:
> On Thu, May 16, 2019 at 06:58:43PM -0400, Tom Lane wrote:
> >Thomas Munro writes:
> >> On Fri, May 17, 2019 at 4:39 AM Tomas Vondra
> >> wrote:
> >>> I kinda like the idea with increasing the spaceAllowed value. Essentially,
> >>> if we
On Thu, May 16, 2019 at 06:58:43PM -0400, Tom Lane wrote:
Thomas Munro writes:
On Fri, May 17, 2019 at 4:39 AM Tomas Vondra
wrote:
I kinda like the idea with increasing the spaceAllowed value. Essentially,
if we decide adding batches would be pointless, increasing the memory
budget is the
On Fri, May 17, 2019 at 12:45 AM Korry Douglas wrote:
> It sounds like there is no reliable way to get the information that I’m
> looking for, is that right?
Correct. And if there were, it could only be used to write bugs. Let
me see if I can demonstrate... I'll use the file_fdw patch from
Thomas Munro writes:
> On Fri, May 17, 2019 at 4:39 AM Tomas Vondra
> wrote:
>> I kinda like the idea with increasing the spaceAllowed value. Essentially,
>> if we decide adding batches would be pointless, increasing the memory
>> budget is the only thing we can do anyway.
> But that's not OK,
On Fri, May 17, 2019 at 10:21:56AM +1200, Thomas Munro wrote:
On Fri, May 17, 2019 at 4:39 AM Tomas Vondra
wrote:
I think this is a step in the right direction, but as I said on the other
thread(s), I think we should not disable growth forever and recheck once
in a while. Otherwise we'll end
On Fri, May 17, 2019 at 4:39 AM Tomas Vondra
wrote:
> I think this is a step in the right direction, but as I said on the other
> thread(s), I think we should not disable growth forever and recheck once
> in a while. Otherwise we'll end up in sad situation with non-uniform data
> sets, as poined
On Fri, May 17, 2019 at 9:42 AM Thomas Munro wrote:
> pgbench -M prepared read-only transactions per second, 16 client threads:
(That second "16 client threads" line should read "32 client threads".)
--
Thomas Munro
https://enterprisedb.com
On Fri, May 17, 2019 at 5:26 AM Chapman Flack wrote:
> On 5/16/19 12:24 PM, Albert Cervera i Areny wrote:
> > Missatge de Thomas Munro del dia dj., 16 de
> > maig 2019 a les 13:09:
> >> With all three mitigations activated, my little dev machine has gone
> >> from being able to do ~11.8 million
On 2019-May-14, Michael Paquier wrote:
> On Tue, May 14, 2019 at 01:19:30PM +1200, David Rowley wrote:
> > When I wrote the code I admit that I was probably wearing my
> > object-orientated programming hat. I had in mind that the whole
> > function series would have made a good class. Passing
Hi,
On 2019-05-16 13:59:47 -0700, Melanie Plageman wrote:
> On Wed, May 15, 2019 at 10:32 PM Ashwin Agrawal wrote:
>
> >
> > The second index would help to hold the session after inserting the tuple
> > in unique index but before completing the speculative insert. Hence, helps
> > to create the
On Wed, May 15, 2019 at 10:32 PM Ashwin Agrawal wrote:
>
> The second index would help to hold the session after inserting the tuple
> in unique index but before completing the speculative insert. Hence, helps
> to create the condition easily. I believe order of index insertion is
> helping here
On Thu, May 16, 2019 at 1:05 PM Peter Geoghegan wrote:
> Actually, now that I look back at how page deletion worked 5+ years
> ago, I realize that I have this slightly wrong: the leaf level check
> is not sufficient to figure out if the parent's right sibling is
> pending deletion (which is
On Mon, May 13, 2019 at 9:09 PM Peter Geoghegan wrote:
> Even when that happens, the index is already considered corrupt by
> VACUUM, so the same VACUUM process that could in theory be adversely
> affected by removing the half-dead internal page check will complain
> about the page when it gets
On Thu, May 16, 2019 at 2:56 PM Fujii Masao wrote:
> Yes. Thanks for the comment!
> Attached is the updated version of the patch.
> It adds such common rule.
I'm not sure how much value it really has to define
opt_boolean_or_string_or_numeric. It saves 1 line of code in each of
3 places, but
On Wed, May 15, 2019 at 2:52 AM Andres Freund wrote:
>
> Hi,
>
> On 2019-05-15 02:45:21 +0900, Fujii Masao wrote:
> > VACUUM fails to parse 0 and 1 as boolean value
> >
> > The document for VACUUM explains
> >
> > boolean
> > Specifies whether the selected option should be turned on or
On 5/16/19 12:24 PM, Albert Cervera i Areny wrote:
> Missatge de Thomas Munro del dia dj., 16 de
> maig 2019 a les 13:09:
>> With all three mitigations activated, my little dev machine has gone
>> from being able to do ~11.8 million baseline syscalls per second to
>
> Did you mean "1.8"?
Not in
> 15 мая 2019 г., в 15:06, Andrey Borodin написал(а):
>
> Owners of AMD and ARM devices are welcome.
Yandex hardware RND guys gave me ARM server and Power9 server. They are looking
for AMD and some new Intel boxes.
Meanwhile I made some enhancements to test suit:
1. I've added Shakespeare
On Thu, May 16, 2019 at 01:22:31PM +1200, Thomas Munro wrote:
...
Here's a quick hack to show that a 95% cut-off fixes those examples.
I don't really know how to choose the number, but I suspect it should
be much closer to 100 than 50. I think this is the easiest of three
fundamental problems
Missatge de Thomas Munro del dia dj., 16 de
maig 2019 a les 13:09:
>
> On Wed, May 15, 2019 at 1:13 PM Andres Freund wrote:
> > > I've run a quick pgbench benchmark:
> > >
> > > *Without* disabling SMT, for readonly pgbench, I'm seeing regressions
> > > between 7-11%, depending on the size of
Hi!
Greetings from OSGeo Code sprint in Minneapolis :)
We're trying to make FULL JOIN on equality of geometry and can't figure out
why it doesn't work.
Here's reproducer, it works on bytea but not on PostGIS geometry throwing
out
ERROR: FULL JOIN is only supported with merge-joinable or
Also works fine according to my testing. Documentation is also clear.
Thanks for this useful patch.
Re-bonjour Daniel,
This attached version does:
- ensure that warnings appear just before its
- add the entry in psql's help
- redefine the function boundary so that timing is cleaner
- include somehow improved tests
\errverbose seems to no longer work with the patch:
Here is a v3 which
On Thu, May 16, 2019 at 02:28:03PM +0100, Dean Rasheed wrote:
On Mon, 13 May 2019 at 23:36, Tomas Vondra wrote:
Yeah. I suggest we add a simple pg_stats_ext view, similar to pg_stats.
It would:
(1) translate the schema / relation / attribute names
I don't see why translating column
On Mon, 13 May 2019 at 23:36, Tomas Vondra wrote:
>
> Yeah. I suggest we add a simple pg_stats_ext view, similar to pg_stats.
> It would:
>
> (1) translate the schema / relation / attribute names
>
> I don't see why translating column indexes to names would be fiddly.
> It's a matter of
> That's only a superficial problem. You don't even know if or when the
> workers that are launched will all finish up running your particular
> node, because (for example) they might be sent to different children
> of a Parallel Append node above you (AFAICS there is no way for a
> participant
On Wed, May 15, 2019 at 1:13 PM Andres Freund wrote:
> > I've run a quick pgbench benchmark:
> >
> > *Without* disabling SMT, for readonly pgbench, I'm seeing regressions
> > between 7-11%, depending on the size of shared_buffers (and some runtime
> > variations). That's just on my laptop, with
Thanks Tomas.
I will follow this problem on your thread. This thread could be terminated.
On Thu, May 16, 2019 at 3:58 AM Tomas Vondra
wrote:
> On Wed, May 15, 2019 at 06:19:38PM +0800, Hubert Zhang wrote:
> >Hi all,
> >
> >When we build hash table for a hash join node etc., we split tuples
Bonjour Daniel,
IMHO this new setting should be on by default: few people know about \; so
it would not change anything for most, and I do not see why those who use
it would not be interested by the results of all the queries they asked for.
I agree with your opinion.
Ok. I did not yet
On Wed, May 15, 2019 at 10:46:39AM -0400, Tom Lane wrote:
> Andres Freund writes:
>> On May 15, 2019 7:20:34 AM PDT, David Fetter wrote:
>>> Indeed. I think we should move our regression tests to TAP and
>>> dispense with this.
>
>> -inconceivably much
>
> Yeah, that's not happening.
+1 to
On Wed, May 15, 2019 at 11:54 AM Andres Freund wrote:
> Hi,
>
> On 2019-04-25 15:43:15 -0700, Andres Freund wrote:
>
> > > 3) nodeTidscan, skipping over too large tids
> > >I think this should just be moved into the AMs, there's no need to
> > >have this in nodeTidscan.c
> >
> > I think
43 matches
Mail list logo
