>
> Here's a not-really-tested draft patch for that.
>
I don't know the parallel code so I'm not going to comment on the overall
patch, but a thought on ExecSetTupleBound().
That function is getting a number of cases where we're doing recursion for
a single child (result, gather, gather-merge).
On Thu, Aug 24, 2017 at 12:38 PM, Masahiko Sawada wrote:
> PostgreSQL 9.6 introduced the priority-based multiple synchronous
> replication and PostgreSQL 10 introduced the quorum-based one.
> Initially I was thinking to use both synchronous replication ways in
> combination
On Wed, Aug 23, 2017 at 7:39 PM, Jesper Pedersen
wrote:
> On 08/23/2017 07:38 AM, Amit Kapila wrote:
>>
>> Thanks for the new version. I again looked at the patches and fixed
>> quite a few comments in the code and ReadMe. You have forgotten to
>> update README for
Never mind. I take that back. The problem is not in community code.
Cheers
Serge
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
Hi Amit,
On Wed, Aug 23, 2017 at 5:08 PM, Amit Kapila wrote:
> On Tue, Aug 22, 2017 at 7:24 PM, Ashutosh Sharma
> wrote:
>> On Tue, Aug 22, 2017 at 3:55 PM, Amit Kapila wrote:
>>
>> Okay, I got your point now. I think,
On Thu, Aug 24, 2017 at 12:38 PM, Bossart, Nathan wrote:
> On 8/18/17, 12:56 AM, "Michael Paquier" wrote:
> According to the docs, VACUUM and ANALYZE "do not support recursing over
> inheritance hierarchies" [1]. However, we need a list of OIDs
Hi
2017-08-24 5:50 GMT+02:00 Fabien COELHO :
>
> Hello Pavel,
>
> I have added the patch to the next commitfest.
>
> Patch applies, compiles, works.
>
> I'm okay with the names graw/graw+, and for having such short-hands.
>
> Missing break in switch, even if last item and
Hello Pavel,
I have added the patch to the next commitfest.
Patch applies, compiles, works.
I'm okay with the names graw/graw+, and for having such short-hands.
Missing break in switch, even if last item and useless, because other
items do it... Also should be added at its place in
Hi all,
PostgreSQL 9.6 introduced the priority-based multiple synchronous
replication and PostgreSQL 10 introduced the quorum-based one.
Initially I was thinking to use both synchronous replication ways in
combination but it's not supported yet for now. It's useful for some
use cases where for
On Wed, Aug 23, 2017 at 6:55 PM, Douglas Doole wrote:
> From previous experience, pushing the limit to the workers has the potential
> to be a big win .
Here's a not-really-tested draft patch for that.
> I haven't played with parallel mode at all yet. Is it possible to
Hello Alik,
I am attaching patch v7.
Patch generates multiple warnings with "git apply", apparently because of
end-of-line spaces, and fails:
pgbench-zipf-07v.patch:52: trailing whitespace.
{
pgbench-zipf-07v.patch:53: trailing whitespace.
"random_zipfian", 3,
While reviewing another patch, I figured out at least one potential issue
on windows when handling execution status.
The attached v11 small updates is more likely to pass on windows.
--
Fabien.diff --git a/src/bin/pgbench/exprscan.l b/src/bin/pgbench/exprscan.l
index dc1367b..8255eff 100644
* Noah Misch (n...@leadboat.com) wrote:
> On Tue, Aug 15, 2017 at 10:24:34PM +0200, Tobias Bussmann wrote:
> > I've tested the new \gx against 10beta and current git HEAD. Actually one
> > of my favourite features of PostgreSQL 10! However in my environment it was
> > behaving strangely. After
On 4/6/17 15:01, Peter Eisentraut wrote:
> On 2/15/17 11:19, Peter Eisentraut wrote:
>> So I would like to have a background worker limit per user, as you
>> allude to. Attached is a patch that implements a GUC setting
>> max_worker_processes_per_user.
>>
>> Besides the uses for background
>
> Buildfarm members with force_parallel_mode=regress are failing now. I
> haven't had a chance to investigate exactly what's going on here, but
> I think there are probably several issues:
>
Not an auspicious beginning for my first patch :-(
> 3. However, even if it did that, it would only
On Mon, Aug 21, 2017 at 2:43 PM, Robert Haas wrote:
> Works for me. While I'm sure this won't eclipse previous achievements
> in this area, it still seems worthwhile. So committed with one minor
> change to shorten a long-ish line.
Buildfarm members with
On Wed, Aug 23, 2017 at 12:42 PM, Andres Freund wrote:
> I don't think that's sufficient. make, and especially check-world,
> should have a decent coverage of the code locally. Without having to
> know about options like force_parallel_mode=regress. As e.g. evidenced
> by the
On 7/6/17 21:06, Thomas Munro wrote:
> On Sat, Jul 1, 2017 at 6:38 AM, Peter Eisentraut
> wrote:
>> On 6/27/17 01:21, Thomas Munro wrote:
>>> Commit ea9df812d8502fff74e7bc37d61bdc7d66d77a7f got rid of
>>> FirstPredicateLockMgrLock, but it's still referred to in a
On 08/22/2017 11:04 PM, Masahiko Sawada wrote:
> WARNING: what you did is ok, but you might have wanted to do something else
>
> First of all, whether or not that can properly be called a warning is
> highly debatable. Also, if you do that sort of thing to your spouse
> and/or children, they
In parse_utilcmd.c: transformIndexConstraint() resides the following piece
of code:
/* * For UNIQUE and PRIMARY KEY, we just have a list of column names. * *
Make sure referenced keys exist. If we are making a PRIMARY KEY index, *
also make sure they are NOT NULL, if possible. (Although we
On 2017-08-23 09:45:38 -0400, Robert Haas wrote:
> On Wed, Aug 23, 2017 at 1:46 AM, Andres Freund wrote:
> > For later commits in the series:
> > - Afaict the whole shared tupledesc stuff, as tqueue.c before, is
> > entirely untested. This baffles me. See also [1]. I can
On 24 December 2015 at 11:03, Caleb Meredith wrote:
> There should be a way to do separate read/write security barriers for
> updatable views. I'll start by addressing the problem, state some potential
> solutions with the current software, and finally end with 2
On 08/23/2017 07:38 AM, Amit Kapila wrote:
Thanks for the new version. I again looked at the patches and fixed
quite a few comments in the code and ReadMe. You have forgotten to
update README for the changes in vacuum patch
(0003-Improve-locking-startegy-during-VACUUM-in-Hash-Index_v7). I
On Wed, Aug 23, 2017 at 11:05 AM, Haribabu Kommi
wrote:
>
>
> On Mon, Aug 21, 2017 at 7:25 PM, Amit Kapila
> wrote:
>>
>> On Mon, Aug 21, 2017 at 12:58 PM, Haribabu Kommi
>> wrote:
>> >
>> > On Sun, Aug 13, 2017 at
On Wed, Aug 23, 2017 at 1:46 AM, Andres Freund wrote:
> For later commits in the series:
> - Afaict the whole shared tupledesc stuff, as tqueue.c before, is
> entirely untested. This baffles me. See also [1]. I can force the code
> to be reached with
On 8/22/17 01:19, Ioseph Kim wrote:
> 2017-08-22 14:06:21.697 KST [306] 로그: logical replication apply
> worker for subscription "replica_a" has started
> 2017-08-22 14:06:21.698 KST [306] 오류: 발행 서버에 연결 할 수 없음:
> ??? ??? ? ??: ??? ???
> "localhost" (::1) ??? ?? ???,
> 5432
On Tue, Aug 22, 2017 at 8:28 PM, Peter Eisentraut
wrote:
> It seems to me that this code in pg_upgrade/check.c has been useless
> since at least version 9.1:
>
> /* Is it 9.0 but without tablespace directories? */
> if
Hi
2017-08-22 11:22 GMT+02:00 Pavel Stehule :
>
>
> 2017-08-22 10:46 GMT+02:00 Fabien COELHO :
>
>>
>> Hello Pavel,
>>
>> One my idea is introduction new simple output format and execution command
>>> with result in this format.
>>>
>>> It should
On Wed, Aug 23, 2017 at 11:58 PM, Thomas Munro
wrote:
> On Wed, Aug 23, 2017 at 5:46 PM, Andres Freund wrote:
>> - Afaict GetSessionDsmHandle() uses the current rather than
>> TopMemoryContext. Try running the regression tests under
>>
On Wed, Aug 23, 2017 at 5:46 PM, Andres Freund wrote:
> Committing 0003. This'll probably need further adjustment, but I think
> it's good to make progress here.
Thanks!
> Changes:
> - pgindent'ed after adding the necessary typedefs to typedefs.list
> - replaced INT64CONST w
On Tue, Aug 22, 2017 at 7:24 PM, Ashutosh Sharma wrote:
> On Tue, Aug 22, 2017 at 3:55 PM, Amit Kapila wrote:
>
> Okay, I got your point now. I think, currently in _hash_kill_items(),
> if an overflow page is pinned we do not check if it got
On Mon, Aug 21, 2017 at 12:07 PM, Amit Langote
wrote:
> I've been working on implementing a way to perform plan-time
> partition-pruning that is hopefully faster than the current method of
> using constraint exclusion to prune each of the potentially many
>
Hi,
Attached is the patch to implement partition-wise aggregation/grouping.
As explained earlier, we produce a full aggregation for each partition when
partition keys are leading group by clauses and then append is performed.
Else we do a partial aggregation on each partition, append them and
Hi,
On 2017-08-10 15:23:06 +1000, Vaishnavi Prabakaran wrote:
> Andres Freund wrote :
> > If you were to send a gigabyte of queries, it'd buffer them all up in
> memory... So some
> >more intelligence is going to be needed.
>
> Firstly, sorry for the delayed response as I got busy with other
>
On 23 August 2017 at 08:18, Michael Paquier wrote:
> On Wed, Aug 23, 2017 at 10:59 AM, Masahiko Sawada
> wrote:
>> On Tue, Aug 22, 2017 at 3:23 PM, Simon Riggs wrote:
>>> e.g.
>>> replace RelationGetRelationName() with
On Wed, Aug 23, 2017 at 12:56 PM, Konstantin Knizhnik
wrote:
>
>
> On 22.08.2017 17:27, Konstantin Knizhnik wrote:
>
>
>
> On 18.08.2017 04:33, Robert Haas wrote:
>
>
> It seems like a somewhat ad-hoc approach; it supposes that we can take any
> query produced by
On 2017/08/22 9:55, Amit Langote wrote:
On 2017/08/22 1:08, Robert Haas wrote:
On Mon, Aug 21, 2017 at 7:45 AM, Etsuro Fujita
wrote:
If there are no objections, I'll add this to the open item list for v10.
This seems fairly ad-hoc to me. I mean, now you have
On 2017-08-23 09:52:45 +0900, Michael Paquier wrote:
> On Wed, Aug 23, 2017 at 2:28 AM, Marco Nenciarini
> wrote:
> > I have noticed that after the 9.4.13 release PostgreSQL reliably fails
> > to shutdown with smart and fast method if there is a running walsender.
On 22.08.2017 17:27, Konstantin Knizhnik wrote:
On 18.08.2017 04:33, Robert Haas wrote:
It seems like a somewhat ad-hoc approach; it supposes that we can
take any query produced by deparseSelectStmtForRel() and stick a
LIMIT clause onto the very end and all will be well. Maybe that's
On Wed, Aug 23, 2017 at 10:59 AM, Masahiko Sawada wrote:
> On Tue, Aug 22, 2017 at 3:23 PM, Simon Riggs wrote:
>> e.g.
>> replace RelationGetRelationName() with
>> RelationGetOptionallyQualifiedRelationName()
>> and then control whether we include
On Aug 21, 2017 07:47, "Simon Riggs" wrote:
On 18 August 2017 at 15:40, Alvaro Herrera wrote:
> Ildar Musin wrote:
>
>> While we've been developing pg_pathman extension one of the most frequent
>> questions we got from our users was about global
On Wed, Aug 23, 2017 at 3:04 PM, Masahiko Sawada wrote:
> It seems to me that we should discuss whether we want to keep the some
> syntax such as 'a,b', 'N(a,b)' before thinking whether or not that
> making the quorum commit the default behavior of 'N(a,b)' syntax. If
> we
On Sat, Aug 19, 2017 at 12:28 AM, Robert Haas wrote:
> On Thu, Aug 17, 2017 at 1:13 AM, Michael Paquier
> wrote:
>> I had in mind a ereport(WARNING) in create_syncrep_config. Extra
>> thoughts/opinions welcome.
>
> I think for v10 we should just
43 matches
Mail list logo