On 2018/02/07 1:36, Robert Haas wrote:
> On Tue, Feb 6, 2018 at 4:55 AM, Amit Langote
> wrote:
>>> I understand why COLLATION_MATCH think that a collation OID match is
>>> OK, but why is InvalidOid also OK? Can you add a comment? Maybe some
>>> test cases, too?
>>
>> partcollid == InvalidOid mea
On Thu, Feb 8, 2018 at 2:44 AM, Kyotaro HORIGUCHI
wrote:
> Hello, I looked this a bit closer.
>
> In upthread[1] Robert mentioned the exponentially increasing size
> of additional segments.
>
>>> Hmm, I had imagined making all of the segments the same size rather
>>> than having the size grow expo
On 2018-02-08 11:50:17 +1300, Thomas Munro wrote:
> You are asking LLVM to dlopen(""), which doesn't work on my not-Linux,
> explaining the errors I reported in the older thread. The portable
> way to dlopen the main binary is dlopen(NULL), so I think you need to
> pass NULL in to LLVMLoadLibraryP
Hi,
Attached a minor patch for variable name in comment:
s/progress_update/update_progress
---include/server/replication/logical.h
...
35 typedef struct LogicalDecodingContext
36 {
...
68 LogicalOutputPluginWriterUpdateProgress update_progress;
Regards,
--
Atsushi Torikoshi
NIPP
Hi all,
In order to run tests consistently on the whole tree, I use a simple
alias which tests also things like src/test/ssl and src/test/ldap on the
way.
Lately, I am getting annoyed by $subject when working on OpenSSL stuff
as sometimes I need to test things with and without SSL support to make
(2018/02/08 10:40), Robert Haas wrote:
On Wed, Feb 7, 2018 at 6:01 PM, Tom Lane wrote:
The buildfarm's opinion of it is lower than yours. Just eyeballing
the failures, I'd say there was some naivete about the reproducibility
of tuple CTIDs across different platforms. Is there a good reason
th
(2018/02/08 5:39), Robert Haas wrote:
On Thu, Jan 11, 2018 at 2:58 AM, Etsuro Fujita
wrote:
(2017/12/27 20:55), Etsuro Fujita wrote:
Attached is an updated version of the patch.
I revised code/comments a little bit. PFA new version.
I spent a while reading through this today. I see a fe
Hello, I looked this a bit closer.
In upthread[1] Robert mentioned the exponentially increasing size
of additional segments.
>> Hmm, I had imagined making all of the segments the same size rather
>> than having the size grow exponentially. The whole point of this is
>> to save memory, and even i
On 2018/02/08 11:55, Amit Langote wrote:
> Hi Ashutosh.
>
> On 2018/02/07 13:51, Ashutosh Bapat wrote:
>> Here's a new patchset with following changes
>>
>> 1. Rebased on the latest head taking care of partition bound
>> comparison function changes
>
> I was about to make these changes myself whi
On Wed, Feb 07, 2018 at 10:26:50PM -0500, Tom Lane wrote:
> Rafal Pietrak writes:
> > ztk=# create table test (a int, b int, c int, d bool, e int, primary key
> > (a,b,c,d));
> > CREATE TABLE
> > ztk=# create unique index leftone on test (a,b) where d is true;
> > CREATE INDEX
> > ztk=# create uni
On Tue, Feb 6, 2018 at 9:51 PM, Claudio Freire wrote:
> On Tue, Feb 6, 2018 at 4:56 AM, Masahiko Sawada wrote:
>> On Tue, Feb 6, 2018 at 2:55 AM, Claudio Freire
>> wrote:
>>> On Mon, Feb 5, 2018 at 1:53 AM, Masahiko Sawada
>>> wrote:
On Fri, Feb 2, 2018 at 11:13 PM, Claudio Freire
On Wed, Feb 07, 2018 at 11:54:52AM -0500, Peter Eisentraut wrote:
> Here is a patch that gives the tests in the SSL test suite proper names
> instead of just writing out the connection strings. So instead of
>
> # running client tests
> # test that the server doesn't accept non-SSL connections
>
On Wed, Feb 7, 2018 at 10:52 PM, Peter Geoghegan wrote:
>
>
> Apparently there is a pending patch to do better there - the commit
> message of 2f178441 refers to this.
>
>
Thanks. Will look at it.
> > The revised version also supports subqueries in SET targetlist as well as
> > WHEN AND conditi
On Thu, Feb 8, 2018 at 12:13 AM, Claudio Freire wrote:
> On Wed, Feb 7, 2018 at 11:29 PM, Alvaro Herrera
> wrote:
>> Claudio Freire wrote:
>>> On Wed, Feb 7, 2018 at 8:52 PM, Alvaro Herrera
>>> wrote:
>>> >> Waiting as you say would be akin to what the patch does by putting
>>> >> vacuum on it
Rafal Pietrak writes:
> ztk=# create table test (a int, b int, c int, d bool, e int, primary key
> (a,b,c,d));
> CREATE TABLE
> ztk=# create unique index leftone on test (a,b) where d is true;
> CREATE INDEX
> ztk=# create unique index rightone on test (b,c) where d is false;
> CREATE INDEX
> ztk=
On Wednesday, February 7, 2018, Rafal Pietrak
wrote:
> Hi,
>
> I've bumped onto the following problem:
> -screenshot
> ztk=# create table test (a int, b int, c int, d bool, e int, primary key
> (a,b,c,d));
> CREATE TABLE
> ztk=# create unique index
On Wed, Feb 7, 2018 at 11:29 PM, Alvaro Herrera wrote:
> Claudio Freire wrote:
>> On Wed, Feb 7, 2018 at 8:52 PM, Alvaro Herrera
>> wrote:
>> >> Waiting as you say would be akin to what the patch does by putting
>> >> vacuum on its own parallel group.
>> >
>> > I don't think it's the same. We d
On Wed, Feb 7, 2018 at 4:41 PM, Tom Lane wrote:
> Peter Geoghegan writes:
>> It would be nice to get an opinion on this mode_final() + tuplesort
>> memory lifetime business from you, Tom.
>
> I'm fairly sure that that bit in mode_final() was just a hack to make
> it work. If there's a better, mo
On Wed, Feb 07, 2018 at 10:50:12AM -0500, Peter Eisentraut wrote:
> Committed with the separate entries.
Thanks. The result looks fine to me.
--
Michael
signature.asc
Description: PGP signature
Hi Ashutosh.
On 2018/02/07 13:51, Ashutosh Bapat wrote:
> Here's a new patchset with following changes
>
> 1. Rebased on the latest head taking care of partition bound
> comparison function changes
I was about to make these changes myself while revising the fast pruning
patch. Instead, I decide
Hi,
I've bumped onto the following problem:
-screenshot
ztk=# create table test (a int, b int, c int, d bool, e int, primary key
(a,b,c,d));
CREATE TABLE
ztk=# create unique index leftone on test (a,b) where d is true;
CREATE INDEX
ztk=# create uniqu
Claudio Freire wrote:
> On Wed, Feb 7, 2018 at 8:52 PM, Alvaro Herrera
> wrote:
> >> Waiting as you say would be akin to what the patch does by putting
> >> vacuum on its own parallel group.
> >
> > I don't think it's the same. We don't need to wait until all the
> > concurrent tests are done --
On Mon, Feb 5, 2018 at 12:55 PM, Peter Geoghegan wrote:
> Anyway, parallel CREATE INDEX added a new "scan" argument to
> IndexBuildHeapScan(), which caused this patch to bitrot. At a minimum,
> an additional NULL argument should be passed by amcheck. However, I
> have a better idea.
>
> ISTM that
On Wed, Feb 7, 2018 at 6:01 PM, Tom Lane wrote:
> Robert Haas writes:
>> I spent a while reading through this today. I see a few decisions
>> here or there that are debatable, in the sense that somebody else
>> might have chosen to do it differently, but I don't see anything that
>> actually loo
Thanks for the review.
On 2018/02/08 0:04, Robert Haas wrote:
> On Tue, Feb 6, 2018 at 12:52 AM, Amit Langote
> wrote:
>> About renaming es_leaf_result_relations to
>> es_tuple_routing_result_relations, I will defer that to committer. But on
>> second though, maybe we don't need to make this pat
Peter Geoghegan writes:
> On Wed, Jan 17, 2018 at 2:23 PM, Peter Geoghegan wrote:
>> A complicating factor for this fix of mine is that mode_final() seems
>> to have its own ideas about tuple memory lifetime, over and above what
>> tuplesort_getdatum() explicitly promises, as can be seen here:
>>
On Wed, Feb 7, 2018 at 8:52 PM, Alvaro Herrera wrote:
>> Waiting as you say would be akin to what the patch does by putting
>> vacuum on its own parallel group.
>
> I don't think it's the same. We don't need to wait until all the
> concurrent tests are done -- we only need to wait until the trans
On 2/7/18 17:21, Stephen Frost wrote:
> Looks like Nov 15 (which I believe is when the stretch upgrade was done)
> it was upgraded:
>
> 2017-11-15 17:38:55 upgrade openjade:amd64 1.4devel1-21.1 1.4devel1-21.3+b1
>
> That doesn't look like a terribly large version bump to me tho..
You probably ha
On Tue, Feb 6, 2018 at 5:21 PM, Peter Eisentraut
wrote:
> On 9/18/17 22:41, Andres Freund wrote:
>> Rearm statement_timeout after each executed query.
>
> This appears to have broken statement_timeout behavior in master such
> that only every second query is affected by it.
Yeah, I also just ran
Claudio Freire wrote:
> On Wed, Feb 7, 2018 at 7:57 PM, Alvaro Herrera
> wrote:
> > Claudio Freire wrote:
> > Hmm, this solution is not very friendly to the goal of reducing test
> > runtime, particularly since the new test creates a nontrivial-sized
> > table. Maybe we can find a better altern
On Wed, Feb 7, 2018 at 7:57 PM, Alvaro Herrera wrote:
> Claudio Freire wrote:
>
>> - vacuum test on its own parallel group
>
> Hmm, this solution is not very friendly to the goal of reducing test
> runtime, particularly since the new test creates a nontrivial-sized
> table. Maybe we can find a be
Robert Haas writes:
> I spent a while reading through this today. I see a few decisions
> here or there that are debatable, in the sense that somebody else
> might have chosen to do it differently, but I don't see anything that
> actually looks wrong. So, committed.
The buildfarm's opinion of i
Claudio Freire wrote:
> - vacuum test on its own parallel group
Hmm, this solution is not very friendly to the goal of reducing test
runtime, particularly since the new test creates a nontrivial-sized
table. Maybe we can find a better alternative. Can we use some wait
logic instead? Maybe some
Stephen Frost writes:
> * Tom Lane (t...@sss.pgh.pa.us) wrote:
>> We've seen this before, eg
>> https://www.postgresql.org/message-id/51CB39BD.8020205%40pgexperts.com
>> and the conclusion seemed to be that it was from having the wrong version
>> of openjade installed. Was borka upgraded recently
On Thu, Feb 8, 2018 at 3:54 AM, Andres Freund wrote:
> I've pushed v10.0. The big (and pretty painful to make) change is that
> now all the LLVM specific code lives in src/backend/jit/llvm, which is
> built as a shared library which is loaded on demand.
>
> The layout is now as follows:
>
> src/ba
Tom,
* Tom Lane (t...@sss.pgh.pa.us) wrote:
> Stephen Frost writes:
> > While trying to do the PDF builds on borka for 9.6 for tomorrow's
> > release, I'm getting:
>
> > openjade -D . -D . -c
> > /usr/share/sgml/docbook/stylesheet/dsssl/modular/catalog -d
> > ./stylesheet.dsl -t tex -V tex-ba
Tom,
* Tom Lane (t...@sss.pgh.pa.us) wrote:
> Stephen Frost writes:
> > While trying to do the PDF builds on borka for 9.6 for tomorrow's
> > release, I'm getting:
>
> > openjade -D . -D . -c
> > /usr/share/sgml/docbook/stylesheet/dsssl/modular/catalog -d
> > ./stylesheet.dsl -t tex -V tex-ba
Stephen Frost writes:
> While trying to do the PDF builds on borka for 9.6 for tomorrow's
> release, I'm getting:
> openjade -D . -D . -c
> /usr/share/sgml/docbook/stylesheet/dsssl/modular/catalog -d ./stylesheet.dsl
> -t tex -V tex-backend -i output-print -i include-index -V texpdf-output -V
Greetings,
While trying to do the PDF builds on borka for 9.6 for tomorrow's
release, I'm getting:
openjade -D . -D . -c /usr/share/sgml/docbook/stylesheet/dsssl/modular/catalog
-d ./stylesheet.dsl -t tex -V tex-backend -i output-print -i include-index -V
texpdf-output -V '%paper-type%'=A4 -o
Robert Haas writes:
> It seems to me that there was a thread where Tom proposed removing
> support for dynamic_shared_memory_type = none.
I think you're recalling <32138.1502675...@sss.pgh.pa.us>, wherein
I pointed out that
>>> Whether that's worth the trouble is debatable. The current code
>>>
> On 6 February 2018 at 10:17, Arthur Zakirov wrote:
> It is strange. I still can apply both v9 [1] and v10 [2] via 'git
> apply'. And Patch Tester [3] says that it is applied. But maybe
> it is because of my git (git version 2.16.1).
>
> You can try also 'patch -p1':
Yes, looks like the problem
Hi,
On 2018-02-07 20:35:12 +0100, Pierre Ducroquet wrote:
> I also find it more readable and it looks cleaner, insane guys could be able
> to write their own JIT engines for PostgreSQL by patching a single
> file :)
Right - we could easily make the libname configurable if requested.
> Since it
Thank you Metin !
Regards
PAscal
--
Sent from: http://www.postgresql-archive.org/PostgreSQL-hackers-f1928748.html
On Thu, Jan 11, 2018 at 2:58 AM, Etsuro Fujita
wrote:
> (2017/12/27 20:55), Etsuro Fujita wrote:
>> Attached is an updated version of the patch.
>
> I revised code/comments a little bit. PFA new version.
I spent a while reading through this today. I see a few decisions
here or there that are de
On Wednesday, February 7, 2018 3:54:05 PM CET Andres Freund wrote:
> Hi,
>
> I've pushed v10.0. The big (and pretty painful to make) change is that
> now all the LLVM specific code lives in src/backend/jit/llvm, which is
> built as a shared library which is loaded on demand.
>
> The layout is now
Greetings,
* Markus Nullmeier (dq...@uni-heidelberg.de) wrote:
> On 07/02/18 18:31, David Steele wrote:
>
> > This proposal is still in need of review and hasn't really gotten it in
> > the last few CFs.
>
> Agreed.
>
> > Since the feature does not seem like a good fit for the last CF of PG11
>
Hi,
On 2018-01-25 12:09:23 -0500, Robert Haas wrote:
> > Perhaps a short benchmark for 32bit systems using shm_mq wouldn't hurt?
> > I suspect there won't be much of a performance impact, but it's probably
> > worth checking.
>
> I don't think I understand your concern here. If this is used on a
On Tue, Jan 9, 2018 at 9:49 AM, Masahiko Sawada wrote:
>> If I understand correctly, XactLastRecEnd can be set by, for example,
>> a HOT cleanup record, so that doesn't seem like a good thing to use.
>
> Yes, that's right.
>
>> Whether we need to use 2PC across remote nodes seems like it shouldn't
Hi David,
On 07/02/18 18:31, David Steele wrote:
> This proposal is still in need of review and hasn't really gotten it in
> the last few CFs.
Agreed.
> Since the feature does not seem like a good fit for the last CF of PG11
> I am marking it Returned with Feedback.
Is there any chance that it
On Wed, Feb 7, 2018 at 1:24 AM, Pavan Deolasee wrote:
> Here is v15 of the patch.
Cool.
> Initially I was a bit surprised that EvalPlanQual silently ignores the case
> when partition key is updated and a row is moved from one partition to
> another. But then I realised that this is the behaviour
On Tue, Feb 6, 2018 at 8:34 PM, Kyotaro HORIGUCHI
wrote:
> Based on the reason, it fails to run when
> dynamic_shared_memory_type = none and it is accompanied by
> several cleanup complexities. The decision there is we should go
> for just using static shared memory rather than adding complexity
>
On Tue, Feb 6, 2018 at 7:51 AM, Claudio Freire wrote:
> No free space becomes visible during long-running vacuums. That means
> bloat keeps accumulating even though vacuum is freeing space, because
> the FSM doesn't expose that free space.
>
> The extra work incurred in those FSM vacuums isn't use
Here is a patch that gives the tests in the SSL test suite proper names
instead of just writing out the connection strings. So instead of
# running client tests
# test that the server doesn't accept non-SSL connections
ok 1 - sslmode=disable (should fail)
# connect without server root cert
ok 2 -
On Thu, Jan 25, 2018 at 07:51:58PM +0300, Arthur Zakirov wrote:
> Attached new version of the patch.
Here is rebased version of the patch due to changes into dict_ispell.c.
The patch itself wasn't changed.
--
Arthur Zakirov
Postgres Professional: http://www.postgrespro.com
Russian Postgres Compa
On Tue, Feb 6, 2018 at 6:03 PM, Michael Paquier
wrote:
> I am not sure that we would like to give up that easily the property
> that we have now to clean up past temporary files only at postmaster
> startup and only when not in recovery. If you implement that, there is
> a risk that the backend y
On Mon, Jan 22, 2018 at 7:05 AM, Amit Kapila wrote:
> On error, workers should be terminated. What kind of problem do you
> have in mind?
Hmm. Yeah, I guess that makes sense. If the only thing you can do is
fetch from the cursor -- and you have to make sure to lock down
protocol messages as we
On 7 February 2018 at 15:25, Robert Haas wrote:
> Do you plan to press forward with this, then, or what's
> the next step?
>
Yes, I think the results are pretty good so far, especially for the
more non-uniform distributions. AFAICS it solves the 2 original
complaints, and I've not yet seen a case
On 2/7/18 00:14, Michael Paquier wrote:
> On Tue, Feb 06, 2018 at 10:45:52PM -0500, Peter Eisentraut wrote:
>> I think what I had meant to write was something like
>>
>> (t.tgtype & (1 | 66))
>>
>> but maybe it's clearer to write it all out as you did.
>
> If you prefer that, that's fine for m
> - line_eq looks too complex in the normal (not containing NANs)
>cases. We should avoid such complexity if possible.
>
>One problem here is that comparison conceals NANness of
>operands. Conversely arithmetics propagate it. We can converge
>NANness into a number. The attached li
Hi, David!
> 7 февр. 2018 г., в 18:39, David Steele написал(а):
>
> Hi Andrey,
>
> On 1/21/18 5:34 AM, Andrey Borodin wrote:
>> Hello, Alexander!
>>> 16 янв. 2018 г., в 21:42, Andrey Borodin написал(а):
>>> Please find README patch attached.
>>
>> Here's v2 version. Same code, but x2 comments
Hi Andrey,
On 1/21/18 5:34 AM, Andrey Borodin wrote:
> Hello, Alexander!
>> 16 янв. 2018 г., в 21:42, Andrey Borodin написал(а):
>> Please find README patch attached.
>
> Here's v2 version. Same code, but x2 comments. Also fixed important typo in
> readme BFS->DFS. Feel free to ping me any time
Hi Oleg,
On 1/22/18 4:37 PM, Stephen Frost wrote:
> Oleg,
>
> I'm not really sure why this is still in Needs Review as a review was
> posted and I don't see any follow-up. I've changed this to be Waiting
> for Author.
>
> * Antonin Houska (a...@cybertec.at) wrote:
>> Oleg Ivanov wrote:
>>
>>>
On Wed, Feb 7, 2018 at 10:20 AM, Dean Rasheed wrote:
> One thing this new algorithm does do is improve the user's ability to
> get more MCVs by increasing the stats target. I'm not yet convinced
> there should be a separate knob for the RSE cutoff. For that to be
> useful, there would need to be s
On 7 February 2018 at 13:29, Robert Haas wrote:
> On Wed, Feb 7, 2018 at 3:51 AM, Dean Rasheed wrote:
>> Thanks for testing. I agree, this new algorithm seems to stand up
>> pretty well in the testing I've done too. One thing about it that can
>> be tuned is the cutoff threshold for the relative
Hi Tomas,
On 1/22/18 7:05 AM, Amit Kapila wrote:
> On Thu, Jan 18, 2018 at 12:59 AM, Robert Haas wrote:
>> On Wed, Jan 17, 2018 at 8:53 AM, Simon Riggs wrote:
>>
>> Or we could go the other way and try to keep the workers running. I
>> don't really like that because it ties down those workers f
On Tue, Feb 6, 2018 at 12:52 AM, Amit Langote
wrote:
> About renaming es_leaf_result_relations to
> es_tuple_routing_result_relations, I will defer that to committer. But on
> second though, maybe we don't need to make this patch larger than it has
> to be.
+1 for renaming it. I like keeping th
Hi Antonin,
On 1/10/18 5:38 PM, Tom Lane wrote:
> Antonin Houska writes:
>> After having read the thread on your patch I think that the reason you were
>> asked to evaluate performance was that your patch can possibly make syslogger
>> a bottleneck. In contrast, my patch does not prevent user fro
Hi,
I've pushed v10.0. The big (and pretty painful to make) change is that
now all the LLVM specific code lives in src/backend/jit/llvm, which is
built as a shared library which is loaded on demand.
The layout is now as follows:
src/backend/jit/jit.c:
Part of JITing always linked into the se
Robert Haas writes:
> On Tue, Feb 6, 2018 at 9:37 AM, Dagfinn Ilmari Mannsåker
> wrote:
>> Commit 5ded4bd21403e143dd3eb66b92d52732fdac1945 removed support for
>> version-0 function calling convention, and with it the fmgr() function.
>> However, the declaration was left behind in fmgr.h. The at
On Wed, Feb 7, 2018 at 12:50 AM, Kyotaro HORIGUCHI
wrote:
> Hello,
>
> At Tue, 6 Feb 2018 10:41:22 -0300, Claudio Freire
> wrote in
>> On Tue, Feb 6, 2018 at 10:18 AM, Claudio Freire
>> wrote:
>> > On Tue, Feb 6, 2018 at 4:35 AM, Kyotaro HORIGUCHI
>> > wrote:
>> >>> It's starting to look lik
Andres Freund writes:
> On 2018-02-06 15:43:29 -0500, Tom Lane wrote:
>> void* isn't necessarily compatible with function pointers --- there are
>> platforms where they're physically different widths, though possibly
>> you'd never get PG to run on such hardware anyway.
> Fair point. Although we'
On Wed, Feb 7, 2018 at 8:37 AM, Ashutosh Bapat
wrote:
> While looking at the changes in partition.c I happened to look at the
> changes in try_partition_wise_join(). They mark partitions deemed
> dummy by pruning as dummy relations. If we accept those changes, we
> could very well change the way w
On Tue, Feb 6, 2018 at 9:37 AM, Dagfinn Ilmari Mannsåker
wrote:
> Commit 5ded4bd21403e143dd3eb66b92d52732fdac1945 removed support for
> version-0 function calling convention, and with it the fmgr() function.
> However, the declaration was left behind in fmgr.h. The attached patch
> finishes the c
On Wed, Feb 7, 2018 at 6:49 PM, Robert Haas wrote:
> On Wed, Feb 7, 2018 at 3:42 AM, Ashutosh Bapat
> wrote:
>> partprune.c looks to much tied to one feature. I am sure that the
>> functions used for partition pruning can be used by other
>> optimizations as well.
>
> Uh, I don't know about that,
On Wed, Feb 7, 2018 at 3:51 AM, Dean Rasheed wrote:
> Thanks for testing. I agree, this new algorithm seems to stand up
> pretty well in the testing I've done too. One thing about it that can
> be tuned is the cutoff threshold for the relative standard error -- I
> chose 10% completely arbitrarily
On Wed, Feb 7, 2018 at 3:42 AM, Ashutosh Bapat
wrote:
> partprune.c looks to much tied to one feature. I am sure that the
> functions used for partition pruning can be used by other
> optimizations as well.
Uh, I don't know about that, this code looks like it does partition
pruning specifically,
On Tue, Feb 6, 2018 at 7:05 PM, amul sul wrote:
> On Sun, Feb 4, 2018 at 10:47 AM, Amit Kapila wrote:
>> On Fri, Feb 2, 2018 at 2:11 PM, amul sul wrote:
>>> On Fri, Jan 26, 2018 at 11:58 AM, Amit Kapila
>>> wrote:
[]
>>
>> I wonder what will be the behavior of this patch with
>> wal_consis
On Wed, Feb 7, 2018 at 3:42 PM, amul sul wrote:
> On Wed, Feb 7, 2018 at 3:03 PM, Amit Khandekar wrote:
>> On 7 February 2018 at 13:53, amul sul wrote:
>>> Hi,
>>>
>>> If an update of partition key involves tuple movement from one partition to
>>> another partition then there will be a separate
On 7 February 2018 at 17:33, Amit Khandekar wrote:
>
> A quick thinking on how to resolve this makes me wonder if we can
> manage to pass some information through logical decoding that the
> delete is part of a partition key update. This is analogous to how we
> set some information locally in t
On Sat, Feb 3, 2018 at 4:04 AM, Robert Haas wrote:
> On Fri, Jan 26, 2018 at 1:28 AM, Amit Kapila wrote:
>> So, this means that in case of logical replication, it won't generate
>> the error this patch is trying to introduce. I think if we want to
>> handle this we need some changes in WAL and l
Hey all,
I'm attaching the updated patch, it includes
i. The list of Pascal (max_worker_processes was already with
PGDLLIMPORT, so I also added to max_parallel_workers)
ii. Some others in cost.h to make the file more readable.
Best,
Metin
On Tue, Feb 6, 2018 at 10:40 PM, Peter Geoghegan wrote:
On Wed, Feb 7, 2018 at 11:42 PM, tushar wrote:
> I am getting ERROR: could not map dynamic shared memory segment in the log
> file
>
> - Please refer this scenario-
>
> in V11/V10 latest sources
>
> set parallel_setup_cost=0;
> set parallel_tuple_cost=0;
> set max_parallel_workers_per_gather=
Hi ,
I am getting ERROR: could not map dynamic shared memory segment in the
log file
- Please refer this scenario-
in V11/V10 latest sources
set parallel_setup_cost=0;
set parallel_tuple_cost=0;
set max_parallel_workers_per_gather=4;
create table r(n int);
insert into r values (generat
(2018/02/07 5:51), Robert Haas wrote:
On Tue, Feb 6, 2018 at 5:22 AM, Etsuro Fujita
wrote:
While reviewing the
lazy-initialization-of-partition-info-for-tuple-routing patch, I ran
into a grammar mistake in a comment in ExecSetupChildParentMapForLeaf.
Attached is a patch for fixing that.
Comm
(2018/02/05 19:43), Etsuro Fujita wrote:
(2018/02/05 14:34), Amit Langote wrote:
The code in tupconv_map_for_subplan() currently assumes that it can rely
on all leaf partitions having been initialized.
On reflection I noticed this analysis is not 100% correct; I think what
that function actua
On Wed, Feb 7, 2018 at 3:03 PM, Amit Khandekar wrote:
> On 7 February 2018 at 13:53, amul sul wrote:
>> Hi,
>>
>> If an update of partition key involves tuple movement from one partition to
>> another partition then there will be a separate delete on one partition and
>> insert on the other parti
On Tue, Feb 6, 2018 at 9:59 PM, David G. Johnston <
david.g.johns...@gmail.com> wrote:
> On Tue, Feb 6, 2018 at 1:46 PM, Stefan Kaltenbrunner <
> ste...@kaltenbrunner.cc> wrote:
>
>>
>> >
>> > Yes, this used to be the case, and is the reason behind the original
>> > recommendation. It's what they
On 7 February 2018 at 13:53, amul sul wrote:
> Hi,
>
> If an update of partition key involves tuple movement from one partition to
> another partition then there will be a separate delete on one partition and
> insert on the other partition made.
>
> In the logical replication if an update perform
On 4 February 2018 at 12:18, John Naylor wrote:
> I did the same basic eyeball testing I did on earlier patches, and
> this is the best implementation so far. I've attached some typical
> pg_stats contents for HEAD and this patch. More rigorous testing,
> including of planner estimates on real dat
On Tue, Feb 6, 2018 at 3:25 PM, Amit Langote
wrote:
>
> Agreed. partition.c has gotten quite big and actually more than half of
> the code that this patch adds really seems to belong outside of it.
>
>> And it seems to me that the code you're adding
>> here is really quite similar to what we've a
On Tue, Feb 6, 2018 at 7:05 PM, amul sul wrote:
> On Sun, Feb 4, 2018 at 10:47 AM, Amit Kapila wrote:
>> On Fri, Feb 2, 2018 at 2:11 PM, amul sul wrote:
>>> On Fri, Jan 26, 2018 at 11:58 AM, Amit Kapila
>>> wrote:
>>> []
I think you can manually (via debugger) hit this by using
P
On 1 February 2018 at 17:49, Robert Haas wrote:
> One point which I want to emphasize is that the length of the MCV list
> bounds the estimated frequency of non-MCVs in two ways: no non-MCV is
> ever thought to be more frequent than the least-common MCVs, and
> however many non-MCVs we think we ha
On Fri, Dec 22, 2017 at 3:00 PM, Rajkumar Raghuwanshi
wrote:
> On Wed, Dec 20, 2017 at 5:21 PM, Ashutosh Bapat
> wrote:
>>
>> Thanks. Here are some comments
>>
> Thanks Ashutosh for review and suggestions.
>
>>
>> +-- test default partition behavior for range
>> +ALTER TABLE prt1 DETACH PARTITION
Hi,
If an update of partition key involves tuple movement from one partition to
another partition then there will be a separate delete on one partition and
insert on the other partition made.
In the logical replication if an update performed on the master and standby at
the same moment, then repl
On Sun, Feb 4, 2018 at 6:10 PM, Tom Lane wrote:
> Oliver Ford writes:
> > [ 0001-window-frame-v13.patch ]
>
> I've been hacking on this all week (with breaks for release notes) and
> have gotten it into a state that I think is close to committable.
>
> There was quite a lot I didn't like about t
95 matches
Mail list logo
