On 24 August 2015 at 14:29, Tom Lane wrote:
> David Rowley writes:
> > I have to admit I don't much like it either, originally I had this as an
> > extra property that was only seen in EXPLAIN VERBOSE.
>
> Seems like a reasonable design from here.
The attached patch has the format in this way.
On Tue, Aug 25, 2015 at 6:19 AM, Kouhei Kaigai wrote:
>
> > On Fri, Aug 21, 2015 at 7:40 PM, Robert Haas
wrote:
> >
> > It could be possible, but let me summarize what I thought would be
required
> > for above use case. For Parallel Append, we need to push multiple
> > planned statements in cont
Joe Conway writes:
> Do we care that as of 9.5 pg_controldata output is not 100% aligned
> anymore? The culprit is:
> Current track_commit_timestamp setting: off
> Its value is shifted 2 characters to the right with respect to all the
> others. I think it ought to be fixed but thought I'd get op
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Do we care that as of 9.5 pg_controldata output is not 100% aligned
anymore? The culprit is:
Current track_commit_timestamp setting: off
Its value is shifted 2 characters to the right with respect to all the
others. I think it ought to be fixed but
Fujita-san,
How about your opinion towards the solution?
CF:Sep will start next week, so I'd like to make a consensus of
the direction, at least.
Thanks,
--
NEC Business Creation Division / PG-Strom Project
KaiGai Kohei
> -Original Message-
> From: pgsql-hackers-ow...@postgresql.org
>
> On Fri, Aug 21, 2015 at 7:40 PM, Robert Haas wrote:
> >
> > On Tue, Aug 18, 2015 at 11:27 PM, Amit Kapila
> > wrote:
> > >> Here is one other issue I found. Existing code assumes a TOC segment has
> > >> only one contents per node type, so it uses pre-defined key (like
> > >> PARALLEL_KEY_SCAN
Greg Stark writes:
> Attached is the pg_regress diff. I believe they are all user-visible
> effects of non-iee fp math though I would have expected the rounding
> to work right and I'm not clear how gist ends up returning rows in a
> different order.
I concur that these are generally unsurprising
2015-08-24 16:02 GMT+02:00 Tom Lane :
> Heikki Linnakangas writes:
> > On 08/24/2015 08:06 AM, Pavel Stehule wrote:
> >> it works perfectly - but the line
> >> xargs -P 3 -I % sh -c "psql % -q -c 'analyze pg_attribute'; echo %"
> >> is little bit ugly - with some psql option it can be cleaned to
Attached is the pg_regress diff. I believe they are all user-visible
effects of non-iee fp math though I would have expected the rounding
to work right and I'm not clear how gist ends up returning rows in a
different order.
There are still two local changes. The SIGILL handler which is set to
the
"Paragon Corporation" writes:
> Just checking to see if you guys have settled on a date for 9.5.0 release.
No. Considering we don't have a beta out yet, it's not imminent ...
regards, tom lane
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To ma
Just checking to see if you guys have settled on a date for 9.5.0 release.
The PostGIS Dev team would like to release PostGIS 2.2 about or a week or
more before, but not too far ahead of 9.5.0 release.
Thanks,
Regina Obe
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
On Thu, Aug 20, 2015 at 6:00 PM, Tomas Vondra
wrote:
> Hi,
>
> On 08/11/2015 04:38 PM, Jeff Janes wrote:
>
>> When reviewing some recent patches, I decided the statistics gathered
>> for arrays had some pre-existing shortcomings.
>>
>> The main one is that when the arrays contain rare elements t
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
On 08/24/2015 04:38 AM, Andrew Dunstan wrote:
> On 08/23/2015 08:58 PM, Michael Paquier wrote:
>> + Datum pg_config(PG_FUNCTION_ARGS); + +
>> PG_FUNCTION_INFO_V1(pg_config);
>>
>> The declaration of the function is not needed,
>> PG_FUNCTION_INFO_V1 t
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
On 08/24/2015 06:50 AM, Tom Lane wrote:
> Andrew Dunstan writes:
>> On 08/23/2015 08:58 PM, Michael Paquier wrote:
>>> I think that's a good thing to have, now I have concerns about
>>> making this data readable for non-superusers. Cloud deployments
>
On Mon, Aug 24, 2015 at 5:15 PM, Tom Lane wrote:
> Alexander Korotkov writes:
> > On Mon, Aug 10, 2015 at 7:50 PM, Tom Lane wrote:
> >> Hm. So one way or the other we're going to end up violating relational
> >> theory somewhere. OK, I yield: let's say that pg_am has amname, amkind,
> >> amha
On Thu, Aug 20, 2015 at 04:32:19PM +0100, Greg Stark wrote:
>
> That's the problem. initdb tests how many connections can start up
> when writing the default config. But we assume that each process can
> use up to the rlimit file descriptors without running into a
> system-wide limit.
That sounds
Alexander Korotkov writes:
> On Mon, Aug 10, 2015 at 7:50 PM, Tom Lane wrote:
>> Hm. So one way or the other we're going to end up violating relational
>> theory somewhere. OK, I yield: let's say that pg_am has amname, amkind,
>> amhandler, and nothing else. Then we will need SQL functions to
Heikki Linnakangas writes:
> On 08/24/2015 08:06 AM, Pavel Stehule wrote:
>> it works perfectly - but the line
>> xargs -P 3 -I % sh -c "psql % -q -c 'analyze pg_attribute'; echo %"
>> is little bit ugly - with some psql option it can be cleaned to
>> xargs -P3 -I % psql % -q --echo-db -c "analyze
Andrew Dunstan writes:
> On 08/23/2015 08:58 PM, Michael Paquier wrote:
>> I think that's a good thing to have, now I have concerns about making
>> this data readable for non-superusers. Cloud deployments of Postgres
>> are logically going to block the access of this view.
> I don't think it expo
On 08/24/2015 03:46 AM, Simon Riggs wrote:
ALTER TABLE foo ADD PARTITION NEXT;
when a sequence of partitions has been defined
Or perhaps
ALTER TABLE foo ADD PARTITION NEXT nn;
So you can set up, say, a week's worth of daily partitions at once.
I could also imagine a variant that
On 08/24/2015 06:49 AM, Heikki Linnakangas wrote:
On 08/24/2015 08:06 AM, Pavel Stehule wrote:
Hi
I found so a set "psql" and "xargs" is pretty strong. But I miss a psql
option for simple returning current database and continuing in pipeline.
What I am doing:
psql postgres -At -c "select da
On 08/23/2015 08:58 PM, Michael Paquier wrote:
2) No docs or related regression test yet. I will do that if there is
enough interest in this getting committed. So far no one except Andrew
and I have chimed in.
I think that's a good thing to have, now I have concerns about making
this data read
2015-08-24 12:49 GMT+02:00 Heikki Linnakangas :
> On 08/24/2015 08:06 AM, Pavel Stehule wrote:
>
>> Hi
>>
>> I found so a set "psql" and "xargs" is pretty strong. But I miss a psql
>> option for simple returning current database and continuing in pipeline.
>>
>> What I am doing:
>>
>> psql postgre
On 08/24/2015 08:06 AM, Pavel Stehule wrote:
Hi
I found so a set "psql" and "xargs" is pretty strong. But I miss a psql
option for simple returning current database and continuing in pipeline.
What I am doing:
psql postgres -At -c "select datname from pg_database" |
xargs -P 3 -I % psql % -At
On 24 August 2015 at 00:53, Josh Berkus wrote:
> On 08/21/2015 08:34 PM, Jim Nasby wrote:
> > On 8/18/15 12:31 PM, Josh Berkus wrote:
> >> Also this would be useful for range
> >> partitions:
> >>
> >> CREATE PARTITION ON parent_table USING ( start_value );
> >>
> >> ... where start_value is the
Hello Amit,
Can the script be started on its own at all?
I have tried like below which results in same error, also I tried few
other variations but could not succeed.
./avg.py
Hmmm... Ensure that the script is readable and executable:
sh> chmod a+rx ./avg.py
Also check the file:
sh>
26 matches
Mail list logo
