On Mon, Nov 6, 2017 at 3:31 PM, Amit Langote
wrote:
> Attached updated set of patches, including the fix to make the new pruning
> code handle Boolean partitioning.
>
Hi Amit,
I have tried pruning for different values of constraint exclusion GUC
change, not sure exactly how it should behave, bu
Ah, there is one reason not to use a mapping to CTEs to implement MERGE:
it might be faster to use a single query that is a FULL OUTER JOIN of the
source and target to drive the update/insert/delete operations.
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes
On Wed, Nov 8, 2017 at 5:57 PM, Amit Khandekar wrote:
> Thomas, can you please try the attached incremental patch
> regress_locale_changes.patch and check if the test passes ? The patch
> is to be applied on the main v22 patch. If the test passes, I will
> include these changes (also for list_part
Hi David.
Thanks for the review.
(..also looking at the comments you sent earlier today.)
On 2017/11/07 11:14, David Rowley wrote:
> On 7 November 2017 at 01:52, David Rowley
> wrote:
>> Thanks. I'll look over it all again starting my Tuesday morning. (UTC+13)
>
> I have a little more review
On 8 November 2017 at 07:55, Thomas Munro wrote:
> On Tue, Nov 7, 2017 at 8:03 AM, Robert Haas wrote:
>> The changes to trigger.c still make me super-nervous. Hey THOMAS
>> MUNRO, any chance you could review that part?
>
> Looking, but here's one silly thing that jumped out at me while
> getting
On 7 November 2017 at 01:52, David Rowley wrote:
> Thanks. I'll look over it all again starting my Tuesday morning. (UTC+13)
Hi Amit,
I had another look over this today. Apologies if any of the review seems petty.
Here goes:
1. If test seems to be testing for a child that's a partitioned table
Hello,
At Mon, 6 Nov 2017 05:20:50 -0800, Andres Freund wrote in
<20171106132050.6apzynxrqrzgh...@alap3.anarazel.de>
> Hi,
>
> On 2017-10-31 18:43:10 +0900, Kyotaro HORIGUCHI wrote:
> > - distance:
> > how many bytes LSN can advance before the margin defined by
> > max_slot_wal_keep_s
Hi,
* avoids wasting memory on duplicated hash tables
* avoids wasting disk space on duplicated batch files
* avoids wasting CPU executing duplicate subplans
What's the last one referring to?
+static void
+MultiExecParallelHash(HashState *node)
+{
+ switch (BarrierPhase(build_barri
On Wed, Nov 8, 2017 at 11:20 AM, Michael Paquier
wrote:
> On Wed, Nov 8, 2017 at 1:58 AM, Alexander Korotkov
> wrote:
>> On Tue, Nov 7, 2017 at 4:34 PM, Masahiko Sawada
>> wrote:
>>> I understood the necessity of this patch and reviewed two patches.
>>
>> Good, thank you.
>
> That's clearly a bu
On Tue, Nov 7, 2017 at 9:58 PM, Fabrízio de Royes Mello
wrote:
> On Tue, Nov 7, 2017 at 1:15 AM, Michael Paquier
> wrote:
>> On Sun, Nov 5, 2017 at 3:14 AM, Fabrízio de Royes Mello
>> wrote:
>> I was going to to hack something like that. That's interesting for the
>> use case Robert has mentione
On Wed, Nov 8, 2017 at 2:51 AM, Robert Haas wrote:
> On Mon, Nov 6, 2017 at 9:57 PM, Amit Kapila wrote:
>
>>> Also, even if inheritance is used, we might still be the
>>> topmost scan/join target.
>>
>> Sure, but in that case, it won't generate the gather path here (due to
>> this part of check
On Tue, Nov 7, 2017 at 8:03 AM, Robert Haas wrote:
> The changes to trigger.c still make me super-nervous. Hey THOMAS
> MUNRO, any chance you could review that part?
Looking, but here's one silly thing that jumped out at me while
getting started with this patch. I cannot seem to convince my mac
On Wed, Nov 8, 2017 at 11:15 AM, Peter Eisentraut wrote:
> Expand empty end tag
Perhaps you missed this patch?
https://www.postgresql.org/message-id/CAJrrPGdkL8TFk+-VivrW637js0v_KM=ub4pBFy=nf0bpafb...@mail.gmail.com
It seems to me that the information within brackets should not be
inside the file
On Wed, Nov 8, 2017 at 1:58 AM, Alexander Korotkov
wrote:
> On Tue, Nov 7, 2017 at 4:34 PM, Masahiko Sawada
> wrote:
>> I understood the necessity of this patch and reviewed two patches.
>
> Good, thank you.
That's clearly a bug fix.
>> diff --git a/contrib/bloom/Makefile b/contrib/bloom/Makefi
On Wed, Nov 8, 2017 at 1:49 AM, Alexander Korotkov
wrote:
> On Tue, Nov 7, 2017 at 4:26 PM, Fabrízio Mello
> wrote:
>> The patch doesn't apply against master:
>>
>> fabrizio@macanudo:/d/postgresql (master)
>> $ git apply /tmp/wal-check-on-bloom-check.patch
>> error: contrib/bloom/Makefile: alread
On Wed, Nov 8, 2017 at 10:38 AM, Masahiko Sawada wrote:
> Hi,
>
> I found that EXTRA_INSTALL is doubly set at both top and bottom of the
> src/test/recovery/Makefile. Is it necessary?
>
> Attached patch fixes this.
Indeed, there is some bad overlap between d851bef and 1148e22a. Better
to CC Simon
On Wed, Nov 8, 2017 at 6:36 AM, Robert Haas wrote:
> On Mon, Nov 6, 2017 at 11:22 PM, Masahiko Sawada
> wrote:
>> Attached the patch for $subject.
>
> Committed.
>
Thank you!
Regards,
--
Masahiko Sawada
NIPPON TELEGRAPH AND TELEPHONE CORPORATION
NTT Open Source Software Center
--
Sent via
Hi,
I found that EXTRA_INSTALL is doubly set at both top and bottom of the
src/test/recovery/Makefile. Is it necessary?
Attached patch fixes this.
Regards,
--
Masahiko Sawada
NIPPON TELEGRAPH AND TELEPHONE CORPORATION
NTT Open Source Software Center
remove_duplicate_setting.patch
Description:
Hi hackers,
Andres, Robert and Peter G rightly complained[1] that my shared
temporary file patch opens a file, then calls
ResourceOwnerEnlargeFiles() which can fail due to lack of memory, and
then registers the file handle to make sure we don't leak it. Doh.
The whole point of the separate Resour
On Wed, Nov 8, 2017 at 9:50 AM, Haribabu Kommi wrote:
> Thanks for the correction. I was not much aware of SGML markup usage.
> While building the documentation, it raises an warning message of "empty
> end-tag".
> So I just added the end tag. Attached the update patch with the suggested
> correct
On Wed, Nov 8, 2017 at 11:11 AM, Michael Paquier
wrote:
> On Wed, Nov 8, 2017 at 9:04 AM, Haribabu Kommi
> wrote:
> > The commit 98267e missed to check the empty SGML tag, attached patch
> > fixes the same.
>
>
>
> - pg_internal.init (found in multiple directories)
> +
On Tue, Nov 07, 2017 at 03:31:22PM -0800, Peter Geoghegan wrote:
> On Tue, Nov 7, 2017 at 3:29 PM, Nico Williams wrote:
> > On Thu, Nov 02, 2017 at 03:25:48PM -0700, Peter Geoghegan wrote:
> >> Nico Williams wrote:
> >> >A MERGE mapped to a DML like this:
> >
> > I needed to spend more time readi
On Wed, Nov 8, 2017 at 9:04 AM, Haribabu Kommi wrote:
> The commit 98267e missed to check the empty SGML tag, attached patch
> fixes the same.
- pg_internal.init (found in multiple directories)
+ pg_internal.init (found in multiple directories)
On Wed, Nov 8, 2017 at 3:03 AM, Simon Riggs wrote:
> On 5 November 2017 at 11:55, Magnus Hagander wrote:
> > On Sat, Nov 4, 2017 at 4:04 AM, Michael Paquier <
> michael.paqu...@gmail.com>
> > wrote:
> >>
> >> On Fri, Nov 3, 2017 at 4:04 PM, Petr Jelinek
> >> wrote:
> >> > Not specific problem t
Hi Peter,
See responses to a couple of points below. I'll respond to the other
points separately (ie with code/comment changes).
On Wed, Nov 8, 2017 at 10:32 AM, Peter Geoghegan wrote:
> On Tue, Nov 7, 2017 at 1:01 PM, Andres Freund wrote:
>> +/*
>> + * Delete a BufFile that was created by Buf
On Wed, Nov 8, 2017 at 8:48 AM, Robert Haas wrote:
> On Tue, Nov 7, 2017 at 4:35 AM, Haribabu Kommi
> wrote:
> > The newly added option is not recommended to be used in normal cases and
> > it is used only for upgrade utilities.
>
> I don't know why it couldn't be used in normal cases. That see
On Tue, Nov 7, 2017 at 3:29 PM, Nico Williams wrote:
> On Thu, Nov 02, 2017 at 03:25:48PM -0700, Peter Geoghegan wrote:
>> Nico Williams wrote:
>> >A MERGE mapped to a DML like this:
>
> I needed to spend more time reading MERGE docs from other RDBMSes.
Please don't hijack this thread. It's abou
On Mon, Nov 06, 2017 at 05:50:21PM +1300, Thomas Munro wrote:
> On Fri, Oct 20, 2017 at 9:05 AM, Nico Williams wrote:
> > Rebased (there were conflicts in the SGML files).
>
> Hi Nico
>
> FYI that version has some stray absolute paths in constraints.source:
>
> -COPY COPY_TBL FROM '@abs_srcdir@
On Thu, Nov 02, 2017 at 03:25:48PM -0700, Peter Geoghegan wrote:
> Nico Williams wrote:
> >A MERGE mapped to a DML like this:
I needed to spend more time reading MERGE docs from other RDBMSes.
The best MERGE so far is MS SQL Server's, which looks like:
MERGE INTO
USING
ON ()
-- o
On Wed, Nov 8, 2017 at 1:42 AM, David Steele wrote:
> On 11/7/17 11:03 AM, Simon Riggs wrote:
>> On 5 November 2017 at 11:55, Magnus Hagander wrote:
>>>
>>> So +1 for documenting the difference in how these are handled, as this is
>>> important to know for somebody writing an external tool for it
On Wed, Nov 8, 2017 at 2:23 AM, Simon Riggs wrote:
> On 31 October 2017 at 12:01, Michael Paquier
> wrote:
>> While the mention about a manual checkpoint happening after a timed
>> one will cause a full range of WAL segments to be recycled, it is not
>> actually true that segments of the prior's
On Tue, Nov 7, 2017 at 2:40 PM, Юрий Соколов wrote:
>> The same is true of unique indexes vs. non-unique.
>
> offtopic: recently I'd a look at setting LP_DEAD in indexes.
> I didn't found huge difference between unique and non-unique indices.
> There is codepath that works only for unique, but it
On Tue, Nov 7, 2017 at 2:36 PM, Tom Lane wrote:
> Peter Geoghegan writes:
>> My point is only that it's worth considering that this factor affects
>> how representative your sympathetic case is. It's not clear how many
>> PageIndexMultiDelete() calls are from opportunistic calls to
>> _bt_vacuum_
On Wed, Nov 8, 2017 at 2:26 AM, Jacob Champion wrote:
> On Mon, Nov 6, 2017 at 6:18 PM, Michael Paquier
> wrote:
>> Did you really test WAL replay?
>
> Is there a way to test this other than installcheck-world? The only
> failure we've run into at the moment is in the snapshot-too-old tests.
> Ma
2017-11-08 1:11 GMT+03:00 Peter Geoghegan :
>
> The same is true of unique indexes vs. non-unique.
offtopic: recently I'd a look at setting LP_DEAD in indexes.
I didn't found huge difference between unique and non-unique indices.
There is codepath that works only for unique, but it is called less
Peter Geoghegan writes:
> My point is only that it's worth considering that this factor affects
> how representative your sympathetic case is. It's not clear how many
> PageIndexMultiDelete() calls are from opportunistic calls to
> _bt_vacuum_one_page(), how important that subset of calls is, and
On Tue, Nov 7, 2017 at 9:26 AM, Jacob Champion wrote:
> On Mon, Nov 6, 2017 at 6:18 PM, Michael Paquier
> wrote:
>> It seems to me that 0001 is good for a committer lookup, that will get
>> rid of all existing bugs. For 0002, what you are proposing is still
>> not a good idea for anything using p
)
On Tue, Nov 7, 2017 at 1:39 PM, Tom Lane wrote:
> So I think we should seriously consider the attached, but it'd be a
> good idea to benchmark it on a wider variety of platforms and test
> cases.
> create unlogged table test3 (
> id integer PRIMARY KEY with (fillfactor=85),
>
On Wed, Nov 8, 2017 at 10:32 AM, Robert Haas wrote:
> On Tue, Nov 7, 2017 at 4:01 PM, Andres Freund wrote:
>> diff --git a/src/backend/utils/resowner/resowner.c
>> b/src/backend/utils/resowner/resowner.c
>> index 4c35ccf65eb..8b91d5a6ebe 100644
>> --- a/src/backend/utils/resowner/resowner.c
>> +
On Tue, Nov 7, 2017 at 4:35 AM, Haribabu Kommi wrote:
> The newly added option is not recommended to be used in normal cases and
> it is used only for upgrade utilities.
I don't know why it couldn't be used in normal cases. That seems like
a totally legitimate thing for somebody to want. Maybe
Robert Haas writes:
> I think it would be a good idea, as Thomas says, to order the qual
> clauses at an earlier stage and then remember our decision. However,
> we have to think about whether that's going to increase planning time
> in a noticeable way. I wonder why we currently postpone this u
On Tue, Nov 7, 2017 at 4:31 AM, Haribabu Kommi wrote:
>> Updated patch attached.
> Patch rebased.
I think the earlier concerns about the performance impact of this are
probably very valid concerns, and I don't see how the new version of
the patch gets us much closer to solving them.
I am also no
I've been getting less and less excited about this patch, because I still
couldn't measure any above-the-noise performance improvement without
artificial exaggerations, and some cases seemed actually slower.
However, this morning I had an epiphany: why are we sorting at all?
There is no requireme
On Mon, Nov 6, 2017 at 11:22 PM, Masahiko Sawada wrote:
> Attached the patch for $subject.
Committed.
--
Robert Haas
EnterpriseDB: http://www.enterprisedb.com
The Enterprise PostgreSQL Company
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subsc
On Tue, Nov 7, 2017 at 1:01 PM, Andres Freund wrote:
> +/*
> + * Build the name for a given segment of a given BufFile.
> + */
> +static void
> +MakeSharedSegmentName(char *name, const char *buffile_name, int segment)
> +{
> + snprintf(name, MAXPGPATH, "%s.%d", buffile_name, segment);
> +}
>
On Tue, Nov 7, 2017 at 4:01 PM, Andres Freund wrote:
> + ResourceOwnerEnlargeFiles(CurrentResourceOwner);
> + ResourceOwnerRememberFile(CurrentResourceOwner, file);
> + VfdCache[file].resowner = CurrentResourceOwner;
>
> So maybe I'm being pedantic here, but wouldn't the right or
On Mon, Nov 6, 2017 at 9:57 PM, Amit Kapila wrote:
>> Well, I suppose that test will fire for a baserel when the total
>> number of baserels is at least 3 and there's no inheritance involved.
>> But if there are 2 baserels, we're still not the topmost scan/join
>> target.
>
> No, if there are 2 ba
Hi,
Here's a review of v24
+set min_parallel_table_scan_size = 0;
+set parallel_setup_cost = 0;
+-- Make a simple relation with well distributed keys and correctly
+-- estimated size.
+create table simple as
+ select generate_series(1, 2) AS id, 'aa';
+alter t
On Mon, Nov 6, 2017 at 5:19 AM, Ashutosh Bapat
wrote:
> IIRC, only thing that changes between plan time quals and execution
> time quals is constaint folding of constant parameters. But I don't
> think we change the selectivity estimates when that's done. At the
> same time, I don't think we shoul
On Mon, Nov 6, 2017 at 4:42 AM, Masahiko Sawada wrote:
>>> I suggest that a good thing to do more or less immediately, regardless
>>> of when this patch ends up being ready, would be to insert an
>>> insertion that LockAcquire() is never called while holding a lock of
>>> one of these types. If t
Hi,
On 2017-11-06 10:56:43 +0530, Amit Kapila wrote:
> On Sun, Nov 5, 2017 at 6:54 AM, Andres Freund wrote
> > On 2017-11-05 01:05:59 +0100, Robert Haas wrote:
> >> skip-gather-project-v1.patch does what it says on the tin. I still
> >> don't have a test case for this, and I didn't find that it
Hi Michael,
On Mon, Nov 6, 2017 at 6:18 PM, Michael Paquier
wrote:
> Did you really test WAL replay?
Is there a way to test this other than installcheck-world? The only
failure we've run into at the moment is in the snapshot-too-old tests.
Maybe we're not configuring with all the tests enabled?
On 31 October 2017 at 12:01, Michael Paquier wrote:
> On Tue, Oct 31, 2017 at 2:00 PM, Simon Riggs wrote:
>> On 30 October 2017 at 18:58, Simon Riggs wrote:
>>> On 30 October 2017 at 15:22, Simon Riggs wrote:
>>>
> You forgot to update this formula in xlog.c:
> distance = (2.0 + Che
Hi!
On Tue, Nov 7, 2017 at 4:34 PM, Masahiko Sawada
wrote:
> I understood the necessity of this patch and reviewed two patches.
>
Good, thank you.
> For /fix-bloom-wal-check.patch, it looks good to me. I found no
> problem. But for wal-check-on-bloom-check.patch, if you want to run
> wal-chec
On Tue, Nov 7, 2017 at 4:26 PM, Fabrízio Mello
wrote:
> 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
>
> The patc
On 11/7/17 11:03 AM, Simon Riggs wrote:
> On 5 November 2017 at 11:55, Magnus Hagander wrote:
>>
>> So +1 for documenting the difference in how these are handled, as this is
>> important to know for somebody writing an external tool for it.
>
> Changes made, moving to commit the attached patch.
On 6 November 2017 at 17:35, Simon Riggs wrote:
> I read that step 3 in Approach2 is some kind of problem in MVCC
> semantics. My understanding is that SQL Standard allows us to define
> what the semantics of the statement are in relation to concurrency, so
> any semantic issue can be handled by d
On 5 November 2017 at 11:55, Magnus Hagander wrote:
> On Sat, Nov 4, 2017 at 4:04 AM, Michael Paquier
> wrote:
>>
>> On Fri, Nov 3, 2017 at 4:04 PM, Petr Jelinek
>> wrote:
>> > Not specific problem to this patch, but I wonder if it should be made
>> > more clear that those files (there are coupl
On Tue, Nov 7, 2017 at 1:35 PM, Bossart, Nathan wrote:
>
> On 11/7/17, 9:13 AM, "Fabrízio Mello" wrote:
> >> int save_nestlevel;
> >> + boolrel_lock;
> >>
> >
> > Just remove the additional tab indentation before rel_lock variable.
>
> I've removed the extra tab in v4.
>
On 2017-11-07 12:12:02 -0300, Claudio Freire wrote:
> If you need it. I'm not particularly fond of writing code before it's needed.
+1
> Otherwise, if it's a rarely-encountered corner case, I'd recommend
> simply calling the stdlib's qsort.
FWIW, we always map qsort onto our own implementation:
On Tue, Nov 7, 2017 at 11:42 AM, Юрий Соколов wrote:
>
>
> 2017-11-07 17:15 GMT+03:00 Claudio Freire :
>> Aside from requiring all that include magic, if you place specialized
>> sort functions in a reusable header, using it is as simple as
>> including the type-specific header (or declaring the t
The following review has been posted through the commitfest application:
make installcheck-world: not tested
Implements feature: tested, passed
Spec compliant: tested, passed
Documentation:tested, passed
> int save_nestlevel;
> + boolrel_lock;
2017-11-07 17:15 GMT+03:00 Claudio Freire :
>
> On Mon, Nov 6, 2017 at 9:08 PM, Юрий Соколов
wrote:
> > 2017-11-07 1:14 GMT+03:00 Claudio Freire :
> >>
> >> I haven't seen this trick used in postgres, nor do I know whether it
> >> would be well received, so this is more like throwing an idea to se
On Mon, Nov 6, 2017 at 9:08 PM, Юрий Соколов wrote:
> 2017-11-07 1:14 GMT+03:00 Claudio Freire :
>>
>> I haven't seen this trick used in postgres, nor do I know whether it
>> would be well received, so this is more like throwing an idea to see
>> if it sticks...
>>
>> But a way to do this without
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
The patch doesn't apply against master anymore:
fabrizio@macanudo:/d/postgre
On Fri, Sep 29, 2017 at 10:32 PM, Alexander Korotkov
wrote:
> On Wed, Sep 6, 2017 at 5:06 PM, Alexander Korotkov
> wrote:
>>
>> On Wed, Sep 6, 2017 at 4:08 PM, Alexander Korotkov
>> wrote:
>>>
>>> I just realized that these lines of contrib/bloom/t/001_wal.pl don't
>>> check that queries give sa
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
The patch doesn't apply against master:
fabrizio@macanudo:/d/postgresql (mas
On Tue, Nov 7, 2017 at 1:15 AM, Michael Paquier
wrote:
>
> On Sun, Nov 5, 2017 at 3:14 AM, Fabrízio de Royes Mello
> wrote:
> > On Sat, Nov 4, 2017 at 1:23 AM, Michael Paquier <
michael.paqu...@gmail.com>
> > wrote:
> >> On Fri, Nov 3, 2017 at 1:55 PM, Fabrízio de Royes Mello
> >> wrote:
> >> >>
Hello, thanks for the new patch.
0004 failed to be applied on the underneath patches.
At Sun, 5 Nov 2017 15:54:19 +0100, Emre Hasegeli wrote in
> > I am not sure how useful NaNs are in geometric types context, but we
> > allow them, so inconsistent hypot() would be a problem. I will change
>
On Tue, 31 Oct 2017 09:47:57 +0100
Emre Hasegeli wrote:
> > If we want to save this behavior, we should somehow pass a stopword
> > to tsvector composition function (parsetext in ts_parse.c) for
> > counter increment or increment it in another way. Currently, an
> > empty lexemes array is passed
On Mon, Oct 30, 2017 at 9:00 AM, Amit Kapila wrote:
> On Wed, Oct 11, 2017 at 9:24 PM, Robert Haas wrote:
>> On Mon, Oct 9, 2017 at 5:56 AM, Amit Kapila wrote:
>>> How about always returning false for PARAM_EXTERN?
>>
>> Yeah, I think that's what we should do. Let's do that first as a
>> separa
On Thu, 2 Nov 2017 23:02:34 +0800
Craig Ringer wrote:
> On 2 November 2017 at 17:41, Ildus Kurbangaliev
> wrote:
>
> > In this patch compression methods is suitable for MAIN and EXTENDED
> > storages like in current implementation in postgres. Just instead
> > only of LZ4 you can specify any ot
On Thu, Oct 26, 2017 at 10:01 PM, Robert Haas wrote:
> On Mon, Oct 23, 2017 at 7:36 AM, Haribabu Kommi
> wrote:
> > Apologies for not providing much details.
> >
> > pg_dumpall is used to produce the following statements for database,
> >
> > "Create database" (other than default database) or
>
On Wed, Sep 27, 2017 at 6:58 PM, Haribabu Kommi
wrote:
>
> Updated patch attached.
>
Patch rebased.
Regards,
Hari Babu
Fujitsu Australia
pg_stat_walwrites-statistics-view_v10.patch
Description: Binary data
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes
74 matches
Mail list logo