On Wed, Mar 14, 2018 at 8:58 PM, Jesper Pedersen
wrote:
> Hi,
>
> Given
>
> -- test.sql --
> CREATE TABLE t1 (
> a integer NOT NULL,
> b integer NOT NULL
> ) PARTITION BY HASH (b);
> CREATE TABLE t1_p00 PARTITION OF t1 FOR VALUES WITH (MODULUS 4, REMAINDER
> 0);
> CREATE TABLE t1_p01
On Sat, Jul 7, 2018 at 7:45 AM, Amit Kapila wrote:
> On Sat, Jul 7, 2018 at 12:44 AM, Robert Haas wrote:
>> On Fri, Jul 6, 2018 at 9:44 AM, Amit Kapila wrote:
>>> I have tried this idea, but it doesn't completely solve the problem.
>>> The problem is that nodes below LIMIT won't get a chance to
On Friday, July 6, 2018, Brent Kerby wrote:
> Of course if the table has a primary key, then this can be used, but I'm
> wondering how to handle this in the general case where a primary key might
> not exist.
>
Personally, I would consider the lack of a PK a rare and special case...I'd
handle
In a situation where we're using transition relations to capture changes
after UPDATE statements, i.e., using a trigger of the form
CREATE TRIGGER trigger_name AFTER UPDATE ON table_name
REFERENCING OLD TABLE AS old_table NEW TABLE AS new_table
FOR EACH STATEMENT EXECUTE PROCEDURE procedure();
On Sat, Jul 7, 2018 at 12:44 AM, Robert Haas wrote:
> On Fri, Jul 6, 2018 at 9:44 AM, Amit Kapila wrote:
>> I have tried this idea, but it doesn't completely solve the problem.
>> The problem is that nodes below LIMIT won't get a chance to accumulate
>> the stats as they won't be able to call
On Fri, Jul 06, 2018 at 07:18:46PM -0400, Tom Lane wrote:
> Larry Rosenman writes:
> > On Fri, Jul 06, 2018 at 06:40:49PM -0400, Tom Lane wrote:
> >> I do not like the "-Wl,-z,notext" thing at all. It fails to explain
> >> why things are working OK in v11/HEAD, which makes me think that it's
>
On 2018-May-08, Amit Langote wrote:
> I would like to revisit this as a bug fix for get_partition_operator() to
> be applied to both PG 10 and HEAD. In the former case, it fixes the bug
> that constraint exclusion code will fail to prune correctly when partition
> key is of array, enum, range,
Larry Rosenman writes:
> On Fri, Jul 06, 2018 at 06:40:49PM -0400, Tom Lane wrote:
>> I do not like the "-Wl,-z,notext" thing at all. It fails to explain
>> why things are working OK in v11/HEAD, which makes me think that it's
>> band-aiding something rather than really fixing it.
> Following
On Fri, Jul 06, 2018 at 06:05:36PM -0500, Larry Rosenman wrote:
> On Fri, Jul 06, 2018 at 06:40:49PM -0400, Tom Lane wrote:
> > Larry Rosenman writes:
> > > anyone want to look at this, or at least give me a clue on how to add
> > > this to 10 & below?
> >
> > I do not like the "-Wl,-z,notext"
On Fri, Jul 06, 2018 at 03:45:46PM +, Andrew Dunstan wrote:
> I agree that this problem should just be documented, and no further
> fix done. The proposed commit message seems to be too long - I think
> it should mainly just just refer to the mailing list discussion. Other
> than that it seems
On Fri, Jul 06, 2018 at 06:40:49PM -0400, Tom Lane wrote:
> Larry Rosenman writes:
> > anyone want to look at this, or at least give me a clue on how to add
> > this to 10 & below?
>
> I do not like the "-Wl,-z,notext" thing at all. It fails to explain
> why things are working OK in v11/HEAD,
Larry Rosenman writes:
> anyone want to look at this, or at least give me a clue on how to add
> this to 10 & below?
I do not like the "-Wl,-z,notext" thing at all. It fails to explain
why things are working OK in v11/HEAD, which makes me think that it's
band-aiding something rather than really
On Thu, Jul 05, 2018 at 07:47:39AM -0500, Larry Rosenman wrote:
> On Wed, Jul 04, 2018 at 08:37:40PM -0500, Larry Rosenman wrote:
> > On Wed, Jul 04, 2018 at 08:19:48PM -0500, Larry Rosenman wrote:
> > > On Thu, Jul 05, 2018 at 12:56:49PM +1200, Thomas Munro wrote:
> > > > On Thu, Jul 5, 2018 at
> "Peter" == Peter Eisentraut writes:
> On 02.07.18 15:26, Tom Lane wrote:
>> FWIW, I agree with Andres' thought that each contrib module should
>> have its own subdirectory under $(includedir_server). Otherwise
>> we're going to be faced with questions about whether .h files need
>> to
On 05.07.18 14:51, Andrew Gierth wrote:
> Anyone have any objection to putting this into 11beta if it works, as
> well as 12devel?
Yes, I have expressed concerns about this approach elsewhere in this thread.
--
Peter Eisentraut http://www.2ndQuadrant.com/
PostgreSQL Development,
Alexander Korotkov writes:
> I tool a look at this patch. It looks good for me. It applies
> cleanly on last master, builds without warnings, passes tests.
> Functionality seems to be well-covered by documentation and regression
> tests. So, I'm going to commit it if no objections.
AFAIR, the
On 2018-Jul-06, Sergei Kornilov wrote:
> 06.07.2018, 22:35, "Robert Haas" :
> > On Fri, Jul 6, 2018 at 1:26 PM, Fujii Masao wrote:
> >> Hmm... so pg_stat_statements_reset() is allowed to be executed by
> >> pg_read_all_stats role while other stats reset functions like
> >> pg_stat_reset() can
On 26.06.18 09:10, Kyotaro HORIGUCHI wrote:
> --- a/src/bin/initdb/initdb.c
> +++ b/src/bin/initdb/initdb.c
> @@ -984,6 +984,16 @@ test_config_settings(void)
> ok_buffers = 0;
>
>
> + /*
> + * Server doesn't confirm that the server-default DSM
06.07.2018, 22:35, "Robert Haas" :
> On Fri, Jul 6, 2018 at 1:26 PM, Fujii Masao wrote:
>> Hmm... so pg_stat_statements_reset() is allowed to be executed by
>> pg_read_all_stats role while other stats reset functions like
>> pg_stat_reset() can be executed only by superusers. Which looks
>>
On 18.05.18 16:04, Michael Paquier wrote:
> On Fri, May 18, 2018 at 02:42:08PM +0800, Paul Guo wrote:
>> 2018-05-17 21:18 GMT+08:00 Michael Paquier :
>>> You should also add this patch to the next commit fest, development of
>>> v11 is done and it is a stabilization period now, so no new patches
On 05.07.18 18:58, Justin Pryzby wrote:
> I checked on one customer running PG10.4, for which pg_dump takes 8 minutes to
> pg_dump -s.
>
> I imported existing schema to PG12dev (which itself took 25min) and compared:
> patched: 2m33.616s
> unpatched: 7m19.578s
Which patch is that, Jeff's or
Hi,
On 2018-07-06 22:03:12 +0200, Magnus Hagander wrote:
> *If* we can provide the snapshots view of them without too much overhead I
> think it's worth looking into that while *also* proviiding a lower overhead
> interface for those that don't care about it.
I don't see how that's possible
Larry Rosenman writes:
> On Fri, Jul 06, 2018 at 11:35:41AM -0700, Joshua D. Drake wrote:
>> Knowing the errors would be helpful.
> pg_restore: [archiver (db)] Error while PROCESSING TOC:
> pg_restore: [archiver (db)] Error from TOC entry 12; 3079 887963 EXTENSION
> postgis_tiger_geocoder
>
On Fri, Jul 6, 2018 at 8:57 PM, Andres Freund wrote:
> On 2018-07-06 14:49:53 -0400, Robert Haas wrote:
> > I think we also have to ask ourselves in general whether snapshots of
> > this data are worth what they cost. I don't think anyone would doubt
> > that a consistent snapshot of the data
On 07/06/2018 12:34 PM, Robert Haas wrote:
On Fri, Jul 6, 2018 at 3:02 PM, Joshua D. Drake wrote:
Will stats, if we move toward the suggested changes be "less" accurate than
they are now? We already know that stats are generally not accurate but they
are close enough. If we move toward this
On 2018-07-06 12:02:39 -0700, Joshua D. Drake wrote:
> On 07/06/2018 11:57 AM, Andres Freund wrote:
> > On 2018-07-06 14:49:53 -0400, Robert Haas wrote:
> > > I think we also have to ask ourselves in general whether snapshots of
> > > this data are worth what they cost. I don't think anyone would
On Fri, Jul 6, 2018 at 1:26 PM, Fujii Masao wrote:
> Hmm... so pg_stat_statements_reset() is allowed to be executed by
> pg_read_all_stats role while other stats reset functions like
> pg_stat_reset() can be executed only by superusers. Which looks
> strange and inconsistent to me.
Yeah, why
On 2018-Jul-06, Amit Langote wrote:
> On 2018/07/06 6:55, David Rowley wrote:
> > On 6 July 2018 at 09:41, Alvaro Herrera wrote:
> >> On 2018-Jul-05, Peter Eisentraut wrote:
> >>> Committed.
> >>
> >> Thanks for handling this.
> >>
> >> Should we do this in REL_11_STABLE too? I vote yes.
> >
>
On Fri, Jul 06, 2018 at 12:37:26PM -0400, Tom Lane wrote:
> > I don't know if we have a buildfarm animal testing Hungarian. Maybe we
> > need a buildfarm animal or two testing a large number of locales.
>
> I dunno that we need to set up a permanent buildfarm member for this.
> I had been
>
>
> On 6 July 2018 at 14:11, Andres Freund wrote:
>
>> Hi,
>>
>> On 2018-07-06 13:49:37 -0400, Dave Cramer wrote:
>> > There is some undocumented (nothing in the docs) code that allows for
>> > closing reopening the output file for pg_recvlogical.
>> >
>> > Since this doesn't change the name of
On Fri, Jul 6, 2018 at 9:44 AM, Amit Kapila wrote:
> I have tried this idea, but it doesn't completely solve the problem.
> The problem is that nodes below LIMIT won't get a chance to accumulate
> the stats as they won't be able to call InstrStopNode.
I'm not sure I understand. Why not? I see
On 07/06/2018 11:57 AM, Andres Freund wrote:
On 2018-07-06 14:49:53 -0400, Robert Haas wrote:
I think we also have to ask ourselves in general whether snapshots of
this data are worth what they cost. I don't think anyone would doubt
that a consistent snapshot of the data is better than an
On 2018-07-06 14:49:53 -0400, Robert Haas wrote:
> I think we also have to ask ourselves in general whether snapshots of
> this data are worth what they cost. I don't think anyone would doubt
> that a consistent snapshot of the data is better than an inconsistent
> view of the data if the costs
On Fri, Jul 6, 2018 at 10:29 AM, Magnus Hagander wrote:
> I agree that this is definitely something that needs to be considered. I
> took a look some time ago at the same thing, and ran up against exactly that
> one (and at the time did not have time to fix it).
>
> I have not yet had time to
On 6 July 2018 at 14:11, Andres Freund wrote:
> Hi,
>
> On 2018-07-06 13:49:37 -0400, Dave Cramer wrote:
> > There is some undocumented (nothing in the docs) code that allows for
> > closing reopening the output file for pg_recvlogical.
> >
> > Since this doesn't change the name of the file in
On Fri, Jul 06, 2018 at 11:35:41AM -0700, Joshua D. Drake wrote:
> On 07/06/2018 11:27 AM, Larry Rosenman wrote:
> > when I pg_dump -Fc the database and then try to restore it after a
> > create database, I get errors. To get a clean restare I need to do:
>
> Knowing the errors would be helpful.
Hi,
On 2018-07-06 16:58:03 +, Sichen Zhao wrote:
> I am a developer from China, when i using pgbench -l to output log file, the
> pgbench seems dont work, my pgbench version is 9.2.13.
> can anyone help me?
>
> ps: when i using 9.2.23 pgbench, the -l is work.
Given that you say the newer
On 07/06/2018 11:27 AM, Larry Rosenman wrote:
when I pg_dump -Fc the database and then try to restore it after a
create database, I get errors. To get a clean restare I need to do:
Knowing the errors would be helpful.
jD
---
\set DB `echo ${DB}`
CREATE SCHEMA IF NOT EXISTS postgis;
CREATE
I have the following:
\set DB `echo $DB`
CREATE SCHEMA IF NOT EXISTS postgis;
CREATE SCHEMA IF NOT EXISTS topology;
CREATE SCHEMA IF NOT EXISTS tiger;
SET search_path=public,postgis,tiger,topology;
ALTER DATABASE :DB SET search_path=public,postgis,tiger,topology;
\c wm_test
CREATE EXTENSION
Hi,
On 2018-07-06 13:49:37 -0400, Dave Cramer wrote:
> There is some undocumented (nothing in the docs) code that allows for
> closing reopening the output file for pg_recvlogical.
>
> Since this doesn't change the name of the file in the process I'm wondering
> how one might actually use this
There is some undocumented (nothing in the docs) code that allows for
closing reopening the output file for pg_recvlogical.
Since this doesn't change the name of the file in the process I'm wondering
how one might actually use this "feature" ?
I could see it being useful if we were to be able to
On Fri, Jul 6, 2018 at 3:34 AM, Sergei Kornilov wrote:
> Hello
>
>> Currently pg_stat_statements_reset() and other stats reset functions like
>> pg_stat_reset() can be executed only by superusers.
>> But why did you allow pg_read_all_stats role to execute that function,
>> by default? That change
Hi,
I am a developer from China, when i using pgbench -l to output log file, the
pgbench seems dont work, my pgbench version is 9.2.13.
can anyone help me?
ps: when i using 9.2.23 pgbench, the -l is work.
thanks in advance
Best Regards
Sichen Zhao
Andrew Dunstan writes:
> On 06/26/2018 08:20 AM, Arthur Zakirov wrote:
>> I'd like to propose the patch which syncs PostgreSQL snowball stemmers.
>> As Tom pointed [1] stemmers haven't synced for a very long time.
> I agree with Tom that we should sync with the upstream before we do
> anything
The following review has been posted through the commitfest application:
make installcheck-world: not tested
Implements feature: not tested
Spec compliant: not tested
Documentation:not tested
I agree that this problem should just be documented, and no further fix
On 6 July 2018 at 03:30, Thomas Munro wrote:
> On Thu, Jul 5, 2018 at 8:27 AM, Noah Misch wrote:
>>> However, 49bff5300d527 also introduced a similar bug where
>>> subtransaction
>>> commit would fail to release an AccessExclusiveLock, leaving the lock to
>>> be removed sometimes
On 05/08/2018 02:18 AM, Amit Langote wrote:
On 2018/03/01 17:16, Amit Langote wrote:
Added this to CF (actually moved to the September one after first having
added it to the CF that is just getting started).
It seems to me that we don't need to go with my originally proposed
approach to
On Wed, Jul 4, 2018 at 11:23 PM, Tom Lane wrote:
> Kyotaro HORIGUCHI writes:
> > At Mon, 2 Jul 2018 14:25:58 -0400, Robert Haas
> wrote in gmail.com>
> >> Copying the whole hash table kinds of sucks, partly because of the
> >> time it will take to copy it, but also because it means that
On Tue, Jul 3, 2018 at 4:18 PM, Amit Kapila wrote:
> On Mon, Jul 2, 2018 at 6:02 PM, Robert Haas wrote:
>>
>
>> To fix the problem with Limit that you mention, we could just modify
>> nodeLimit.c so that when the state is changed from LIMIT_INWINDOW to
>> LIMIT_WINDOWEND, we also call
On 07/05/2018 02:52 PM, David Rowley wrote:
On 30 June 2018 at 05:40, David Rowley wrote:
I think your idea
to reduce the loops in test 6 from 2000 down to 1001 should be worth
it. I'll try the idea out next week.
The attached changes things to use your way of picking up the search
for the
Hi,
I have started reviewing these patches. I haven't grasped the design
yet. But here are some comments on the first patch.
-clauses = (MergeJoinClause) palloc0(nClauses *
sizeof(MergeJoinClauseData));
+parent->mj_Clauses = (MergeJoinClause) palloc0(nClauses *
Thomas,
We're using a zfs recordsize of 8k to match the PG blocksize of 8k, so what
you're describing is not the issue here.
Thanks,
Jerry
On Thu, Jul 5, 2018 at 3:44 PM, Thomas Munro
wrote:
> On Fri, Jul 6, 2018 at 3:37 AM, Jerry Jelinek
> wrote:
> >> If the problem is specifically the
Hi
I am testing last patch and looks so truncating message and appending "..."
doesn't work.
The slot->len hold trimmed length, not original length.
Regards
Pavel
On Fri, Jul 06, 2018 at 08:05:50AM -0400, Andrew Dunstan wrote:
> On 07/06/2018 07:18 AM, Michael Paquier wrote:
> > For what it's worth, I volunteer to finish the work :)
> >
> > The 2PC patch is really simple, and fixes a data loss issue. The second
> > patch has been looked up by Heikki,
On 07/06/2018 07:18 AM, Michael Paquier wrote:
Robert Haas wrote:
Although the state is now back to "Needs Review", I echo those
sentiments. This issue has now been hanging around for about 18
months.
No, those are my words, not Robert's :-)
For what it's worth, I volunteer to finish
On 4 July 2018 at 21:15, Tsunakawa, Takayuki wrote:
> From: Craig Ringer [mailto:cr...@2ndquadrant.com]
> > I'm assuming you don't want to offer a grant that lets anyone use them
> for
> > anything. But if you have a really broad grant to PostgreSQL, all someone
> > would have to do to inherit
On 06/26/2018 08:20 AM, Arthur Zakirov wrote:
Hello hackers,
I'd like to propose the patch which syncs PostgreSQL snowball stemmers.
As Tom pointed [1] stemmers haven't synced for a very long time.
I copied all source files without changes, except replacing '#include
"../runtime/header.h"'
On 05/17/2018 08:43 PM, Ideriha, Takeshi wrote:
-Original Message-
From: Robert Haas [mailto:robertmh...@gmail.com]
OK, I'm happy enough to commit it then, barring other objections. I was just
going to
just do that but then I realized we're in feature freeze right now, so I
suppose
On Fri, Jul 6, 2018 at 4:29 PM, Etsuro Fujita
wrote:
> (2018/07/04 21:37), Ashutosh Bapat wrote:
>>
>> On Wed, Jul 4, 2018 at 5:36 PM, Etsuro Fujita
>> wrote:
>>>
>>> (2018/07/04 19:04), Ashutosh Bapat wrote:
On Fri, Jun 29, 2018 at 6:21 PM, Etsuro Fujita
wrote:
>
>
Robert Haas wrote:
> Although the state is now back to "Needs Review", I echo those
> sentiments. This issue has now been hanging around for about 18
> months.
For what it's worth, I volunteer to finish the work :)
The 2PC patch is really simple, and fixes a data loss issue. The second
patch
Robert Haas wrote:
> On Fri, Feb 23, 2018 at 11:08 AM, Antonin Houska wrote:
> > I spent some more time thinking about this. What about adding a new strategy
> > number for hash index operator classes, e.g. HTBinaryEqualStrategyNumber?
> > For
> > most types both HTEqualStrategyNumber and
On Thu, Jun 28, 2018 at 1:39 AM, Michael Paquier wrote:
> On Thu, Jan 11, 2018 at 10:35:22PM -0500, Stephen Frost wrote:
>> Magnus, this was your thread to begin with, though I know others have
>> been involved, any chance you'll be able to review this for commit
>> during this CF? I agree that
(2018/07/04 21:37), Ashutosh Bapat wrote:
On Wed, Jul 4, 2018 at 5:36 PM, Etsuro Fujita
wrote:
(2018/07/04 19:04), Ashutosh Bapat wrote:
On Fri, Jun 29, 2018 at 6:21 PM, Etsuro Fujita
wrote:
(2018/06/22 22:54), Ashutosh Bapat wrote:
+ if (enable_partitionwise_join&&
Thanks David!
I did benchmark with pgbench, and see a speedup for INSERT / UPDATE scenarios.
I used range partition.
Benchmark results are as follows.
1. 11beta2 result
part_num | tps_ex | latency_avg | update_latency | select_latency |
insert_latency
On Fri, 6 Jul 2018 08:33:56 +
Taiki Kondo wrote:
> Hi all,
>
> I found typo in Japanese translation of psql.
Good catch!
However, I think you have to submit the whole po file to Patch Tracker[1]
instead of a patch according to the wiki [2].
[1]
On Fri, 29 Jun 2018 17:31:51 +0300
Teodor Sigaev wrote:
> > AFAICS, we'd just have to revert this patch later, so I don't see
> > much value in it.
> True, I suppose we should apply this patch just for consistency, because we
> don't allow expression in included columns.
Yes, this is what I
Hi all,
I found typo in Japanese translation of psql.
Please find attached.
Sincerely,
--
Taiki Kondo
NEC Solution Innovators, Ltd.
diff --git a/src/bin/psql/po/ja.po b/src/bin/psql/po/ja.po
index 34bd8a4e25..fe8dc3804f 100644
--- a/src/bin/psql/po/ja.po
+++ b/src/bin/psql/po/ja.po
@@
On Sat, 30 Jun 2018 14:13:49 -0400
Tom Lane wrote:
> Peter Geoghegan writes:
> > I think that the argument Tom is making is that it might be useful to
> > have statistics on the expression regardless of this -- the expression
> > may be interesting in some general sense. For example, one can
Hi
2018-07-06 9:49 GMT+02:00 Brahmam Eswar :
> Hi ,
>
> I tried to use array_remove to remove elements from an array but it's
> saying function doesn't exist . I'm able to use other array functions.
>
> 1) Capture the results with multiple columns into array .
> 2) if ay results exist then loop
>-Original Message-
>From: Jaime Casanova [mailto:jaime.casan...@2ndquadrant.com]
>Sent: Tuesday, July 3, 2018 11:06 AM
>Thinking on Michael's suggestion of using event triggers, you can create an
>event >trigger to run pg_create_restore_point() on DROP, here's a simple
>example of how
>-Original Message-
>From: Michael Paquier [mailto:mich...@paquier.xyz]
>Sent: Tuesday, July 3, 2018 10:22 AM
>This kind of thing is heavily application-dependent. For example, you would
>likely not care if an operator, who has newly-joined the team in >charge of
>the maintenance of
Hi
PLpgSQL FETCH documentation is has ref on SQL FETCH command. SQL FETCH
allows only int constants as count. PLpgSQL allows any expressions. In this
case documentation is not clear, and people can be messy - and apply SQL
FETCH limits on PLpgSQL FETCH.
Hello Peter,
06.07.2018 00:39, Peter Eisentraut wrote:
> Exactly what order of steps are you executing that doesn't work?
In Centos 7, using the master branch from git:
./configure --enable-tap-tests
make install
make install -C contrib
chown -R postgres:postgres /usr/local/pgsql/
On Wed, 4 Jul 2018 10:46:30 +0200
Peter Eisentraut wrote:
> On 02.07.18 10:38, Daniel Gustafsson wrote:
> >> On 29 Jun 2018, at 18:44, Tom Lane wrote:
> >
> >> +1 for shortening it as proposed by Peter. The existing arrangement
> >> made sense when it was first written, when there were only
On Mon, 2 Jul 2018 14:23:09 -0400
Robert Haas wrote:
> On Thu, Jun 28, 2018 at 5:28 AM, Yugo Nagata wrote:
> > According to the error message, it is not allowed to alter statistics on
> > included column because this is "non-expression column".
> >
> > postgres=# create table test (i int, d
At Fri, 6 Jul 2018 14:26:42 +0900, Michael Paquier wrote
in <20180706052642.gb...@paquier.xyz>
> On Fri, Jul 06, 2018 at 01:07:47PM +0900, Kyotaro HORIGUCHI wrote:
> > Form the reasons above, I'd like to vote +1 for just ERRORing
> > in the case.
>
> Thanks for the lookup. Do you have a good
76 matches
Mail list logo
