2018-03-21 6:24 GMT+01:00 Pavel Stehule :
>
>
> 2018-03-20 18:38 GMT+01:00 Pavel Stehule :
>
>> Hi
>>
>> I am sending new update. The code is less ugly, and the current
>> functionality is +/- final for first stage. It should be good enough for
>> playing and testing this concept.
>>
>> What is su
On Fri, Mar 23, 2018 at 10:00 AM, Amit Langote <
langote_amit...@lab.ntt.co.jp> wrote:
> On 2018/03/23 3:42, Pavan Deolasee wrote:
> > A slightly improved version attached. Apart from doc cleanup based on
> > earlier feedback, fixed one assertion failure based on Rahila's report.
> > This was happ
2018-03-22 20:10 GMT+01:00 Pavel Stehule :
>
>
> 2018-03-22 19:28 GMT+01:00 Pavel Stehule :
>
>>
>>
>> 2018-03-22 18:38 GMT+01:00 Fabien COELHO :
>>
>>>
>>> Hello Pavel,
>>>
>>> Using \pset format csv means overwriting field sep every time - nobody
uses
|
>>>
>>> Yep. The alternativ
On Fri, Mar 23, 2018 at 10:20 AM, Claudio Freire wrote:
> On Thu, Mar 22, 2018 at 3:29 AM, Pavan Deolasee
> wrote:
>>
>> On Thu, Mar 22, 2018 at 7:22 AM, Claudio Freire
>> wrote:
>>>
>>>
>>> If you're not planning on making any further changes, would you mind
>>> posting a coalesced patch?
>>>
>
On Thu, Mar 22, 2018 at 08:42:05AM +0100, Michael Banck wrote:
> Am Donnerstag, den 22.03.2018, 10:33 +0900 schrieb Michael Paquier:
>> Hence, is there any objection to mark this patch as returned with
>> feedback?
>
> I've done so now.
Thanks Michael.
--
Michael
signature.asc
Description: PG
On 2018/03/23 3:42, Pavan Deolasee wrote:
> A slightly improved version attached. Apart from doc cleanup based on
> earlier feedback, fixed one assertion failure based on Rahila's report.
> This was happening when target relation is referenced in the source
> subquery. Fixed that and added a test c
On Tue, Mar 20, 2018 at 1:23 AM, Robert Haas wrote:
> On Sat, Mar 17, 2018 at 1:16 AM, Amit Kapila wrote:
>> Test-1
>> --
>> DO $$
>> DECLARE count integer;
>> BEGIN
>> For count In 1..100 Loop
>> Execute 'explain Select ten from tenk1';
>> END LOOP;
>> END;
>> $$;
>>
>> In the above
On 3/22/18 22:17, Peter Eisentraut wrote:
> So after a day, only the old macOS PowerPC systems have sizeof(bool) == 4.
And this is causing some problems in PL/Perl. I'll look into it.
--
Peter Eisentraut http://www.2ndQuadrant.com/
PostgreSQL Development, 24x7 Support, Remote DBA,
On 2018/03/22 20:48, Pavan Deolasee wrote:
> Thanks. It's looking much better now.
Thanks.
> I think we can possibly move all ON
> CONFLICT related members to a separate structure and just copy the pointer
> to the structure if (map == NULL). That might make the code a bit more tidy.
OK, I tried
On 3/21/18 07:48, Peter Eisentraut wrote:
> On 3/21/18 01:51, Tom Lane wrote:
>> Andres Freund writes:
>>> On March 20, 2018 8:24:41 PM PDT, Michael Paquier
>>> wrote:
Yeah, I agree with that. Just not using stdbool.h in those cases ought
to be fine. Any platforms where sizeof(bool)
On Thu, Mar 22, 2018 at 6:02 PM, Alvaro Herrera wrote:
> Incremental development is a good thing. Trying to do everything in a
> single commit is great when time is infinite or even merely very long,
> but if you run out of it, which I'm sure is common, leaving some things
> out that can be reaso
Peter Geoghegan wrote:
> Pavan hasn't added support for referencing CTEs, which other database
> systems with MERGE have. I think that it ought to be quite doable. It
> didn't take me long to get it working myself, but there wasn't follow
> through on that (I could have posted the patch, which loo
Hi,
while looking at brin_inclusion.c, I've noticed that the comment about
INCLUSION_UNMERGEABLE and INCLUSION_CONTAINS_EMPTY uses incorrect values
(1 instead of 2). Attached is a simple fix.
But perhaps it would be better to use the constants in the comment.
regards
--
Tomas Vondra
On Fri, Mar 23, 2018 at 01:38:38AM +0900, Fujii Masao wrote:
> Personally it looks very intrusive, so I'm feeling inclined to push
> the changes without that refactoring.
Okay. Just moving the list of items from basebackup.c to a dedicated
header is not sufficient though as things like RELCACHE_I
On 2018/03/23 2:51, Robert Haas wrote:
> On Wed, Jan 17, 2018 at 1:03 AM, Amit Langote wrote:
>> On Wed, Jan 17, 2018 at 1:51 PM, Michael Paquier
>> wrote:
>>> On Tue, Jan 16, 2018 at 11:38:58PM -0500, Tom Lane wrote:
Yeah, pg_upgrade already has to cope with cases where the newer version
>>
On Thu, Mar 22, 2018 at 01:36:59PM -0400, Robert Haas wrote:
> Committed.
Thanks.
--
Michael
signature.asc
Description: PGP signature
On 22 March 2018 at 21:16, Laurenz Albe wrote:
> Would it be very difficult to extend that to "if any unique constraints are
> contained in the DISTINCT clause"?
Unfortunately, it's quite a bit more work to make that happen. It's
not just unique constraints that are required to make this work. We
On Thu, Mar 22, 2018 at 3:29 AM, Pavan Deolasee
wrote:
>
> On Thu, Mar 22, 2018 at 7:22 AM, Claudio Freire
> wrote:
>>
>>
>> If you're not planning on making any further changes, would you mind
>> posting a coalesced patch?
>>
>> Notice that I removed the last offset thing only halfway, so it wou
On Thu, Mar 22, 2018 at 1:06 AM, Simon Riggs wrote:
> I'm now proposing that I move to commit this, following my own final
> review, on Tues 27 Mar in 5 days time, giving time for cleanup of
> related issues.
>
> If there are any items you believe are still open, please say so now
> or mention any
On Thu, Mar 22, 2018 at 12:59 AM, Simon Riggs wrote:
>> The point here is that we're primarily talking about two whole tables.
>> That deserves such prominent placement, as that suggests where users
>> might really find MERGE useful, but without being too prescriptive.
>
> The information I have i
On Thu, Mar 22, 2018 at 11:42 AM, Pavan Deolasee
wrote:
> A slightly improved version attached.
You still need to remove this change:
> diff --git a/src/include/miscadmin.h b/src/include/miscadmin.h
> index a4574cd533..dbfb5d2a1a 100644
> --- a/src/include/miscadmin.h
> +++ b/src/include/miscadm
Hi Magnus,
thanks a lot for looking at my patch!
Am Donnerstag, den 22.03.2018, 15:07 +0100 schrieb Magnus Hagander:
> On Sat, Mar 17, 2018 at 10:34 PM, Michael Banck
> wrote:
> > On Fri, Mar 09, 2018 at 10:35:33PM +0100, Michael Banck wrote:
> > > Possibly open questions:
> > >
> > > 1. I have
Daniel Gustafsson writes:
> Being a two-space guy I would like the style to remain that, but I also agree
> that the churn is way too expensive and that it’s considered quite obsolete
> and
> old by many. Cutting that change from the patch makes the remainder more
> palatable.
This stuff seems
The whole IsProjectionFunctionalIndex looks kinda bogus/ugly to me. Set
the boolean to false, but keep evaluating anyway? But then, I thought
the idea was to do this based on the reloption, not by comparing the
expression cost to a magical (unmodifiable) value?
In RelationGetIndexAttrBitmap(), i
The rd_projidx (list of each nth element in the index list that is a
projection index) thing looks odd. Wouldn't it make more sense to have
a list of index OIDs that are projection indexes?
--
Álvaro Herrerahttps://www.2ndQuadrant.com/
PostgreSQL Development, 24x7 Support, Remote
Robert Haas wrote:
> On Wed, Mar 21, 2018 at 10:20 AM, Alvaro Herrera
> wrote:
> > Let's keep this entry open till the last minute.
>
> Ugh, I don't like keeping things open till the last minute all that
> much, especially if they're not being updated. But since this has
> been updated I guess i
On Wed, Mar 21, 2018 at 10:20 AM, Alvaro Herrera
wrote:
> Let's keep this entry open till the last minute.
Ugh, I don't like keeping things open till the last minute all that
much, especially if they're not being updated. But since this has
been updated I guess it's somewhat moot.
Are you going
On Mon, Mar 19, 2018 at 11:57 AM, Robert Haas wrote:
> On Fri, Mar 16, 2018 at 7:35 AM, Rajkumar Raghuwanshi
> wrote:
>> On Fri, Mar 9, 2018 at 1:04 AM, Robert Haas wrote:
>>> Great. Committed 0001. Are you planning any further testing of this
>>> patch series?
>>
>> Sorry I missed the mail.
>
On 03/22/2018 08:51 PM, Tom Lane wrote:
> I wrote:
>> Tomas Vondra writes:
>>> The 0002 part is the main part, unifying the definition of reltuples on
>>> three main places:
>
>> On to this part ...
>
> I've pushed 0002 with several corrections: it did not seem to me that
> you'd correctly propa
I wrote:
> Tomas Vondra writes:
>> The 0002 part is the main part, unifying the definition of reltuples on
>> three main places:
> On to this part ...
I've pushed 0002 with several corrections: it did not seem to me that
you'd correctly propagated what ANALYZE is doing into CREATE INDEX or
pgsta
2018-03-22 19:28 GMT+01:00 Pavel Stehule :
>
>
> 2018-03-22 18:38 GMT+01:00 Fabien COELHO :
>
>>
>> Hello Pavel,
>>
>> Using \pset format csv means overwriting field sep every time - nobody
>>> uses
>>> |
>>>
>>
>> Yep. The alternative is to have a csv-specific separator variable, which
>> does no
On Tue, Feb 27, 2018 at 7:01 AM, Etsuro Fujita
wrote:
> Changes other than that are:
>
> * Fixed typo and revised code/comments
> * Added more regression tests
> * Added docs
>
> Attached is a new version of the patch set.
I took a look at this patch set today but I really don't think we
should c
> On 22 Mar 2018, at 17:19, Tom Lane wrote:
> In short, I'm not sure it's worth thrashing a lot of our translatable
> strings to enforce a debatable style detail.
I thought I had voiced that exact concern in my previous email, but I totally
missed that.
Being a two-space guy I would like the
2018-03-22 18:38 GMT+01:00 Fabien COELHO :
>
> Hello Pavel,
>
> Using \pset format csv means overwriting field sep every time - nobody uses
>> |
>>
>
> Yep. The alternative is to have a csv-specific separator variable, which
> does not seem very useful, must be remembered, but this is indeed debat
Hello,
I'm very interested in pg_stat_statements usage, and I'm very happy to see
you adding plans to it.
Reading other pg_stat_statements threads on this forum, there are also activ
developments to add:
- planing duration,
- first date,
- last_update date,
- parameters for normalized queries,
- .
On Wed, Jan 17, 2018 at 1:03 AM, Amit Langote wrote:
> On Wed, Jan 17, 2018 at 1:51 PM, Michael Paquier
> wrote:
>> On Tue, Jan 16, 2018 at 11:38:58PM -0500, Tom Lane wrote:
>>> Yeah, pg_upgrade already has to cope with cases where the newer version
>>> thinks a table needs a toast table when the
Hello Pavel,
Using \pset format csv means overwriting field sep every time - nobody uses
|
Yep. The alternative is to have a csv-specific separator variable, which
does not seem very useful, must be remembered, but this is indeed
debatable.
I think so dependency on order of psql argument
On Mon, Feb 5, 2018 at 2:14 AM, Michael Paquier
wrote:
> While hacking some stuff, I bumped into the following:
> --- a/src/backend/access/transam/multixact.c
> +++ b/src/backend/access/transam/multixact.c
> @@ -1932,7 +1932,7 @@ ZeroMultiXactMemberPage(int pageno, bool writeXlog)
> * MaybeExten
On Mon, Feb 19, 2018 at 7:27 PM, Tsunakawa, Takayuki
wrote:
> The reason for change is better performance. Robert Haas said open_datasync
> was much faster than fdatasync with NVRAM in this thread:
I also said it would be worse on spinning disks.
Also, Yoshimi Ichiyanagi did not find it to be
Tomas Vondra writes:
> 0001 fixes this by tracking the number of actually indexed rows in the
> build states, just like in the other index AMs.
> A VACUUM or ANALYZE will fix the estimate, of course, but for tables
> that are not changing very much it may take quite a while. So I think
> this is s
On Fri, Feb 23, 2018 at 10:30 PM, Thomas Munro
wrote:
> Here is an attempt at updating parallel.sgml to cover Parallel Hash.
> I will be neither surprised nor offended if Robert would like to put
> it differently!
Looks nice. Committed.
--
Robert Haas
EnterpriseDB: http://www.enterprisedb.com
On Wed, Mar 7, 2018 at 8:53 PM, Peter Geoghegan wrote:
> On Thu, Mar 1, 2018 at 2:47 PM, Peter Geoghegan wrote:
>> No. Just an oversight. Looks like _bt_parallel_build_main() should
>> call pgstat_report_activity(), just like ParallelQueryMain().
>>
>> I'll come up with a patch soon.
>
> Attached
On Thu, Mar 22, 2018 at 6:15 AM, Jeevan Chalke
wrote:
> Leeks cleaner now. Thanks for refactoring it.
>
> I have merged these changes and flatten all previuos changes into the main
> patch.
Committed 0001-0005. I made a few further modifications. These were
mostly cosmetic, but with two excepti
Please excuse my absence from this thread.
On 2 March 2018 at 12:34, Konstantin Knizhnik wrote:
>
>
> On 01.03.2018 22:48, Andres Freund wrote:
>>
>> Hi,
>>
>> I still don't think, as commented upon by Tom and me upthread, that we
>> want this feature in the current form.
The performance benefit
Peter Eisentraut wrote:
> On 3/21/18 19:18, Alvaro Herrera wrote:
> > Here's v8, which addresses all your comments except the doc updates. I
> > added a few more tests, too. Thanks for the review! I intend to commit
> > this shortly, probably not before Friday to give some more time for
> > othe
On Tue, Mar 13, 2018 at 9:48 PM, Michael Paquier wrote:
> On Tue, Mar 13, 2018 at 01:16:27PM +0300, Anastasia Lubennikova wrote:
>> Since these patches contain mostly cosmetic changes and do not break
>> anything, I think it's fine to mark this thread as Ready For Committer
>> without long discuss
On 3/21/18 19:18, Alvaro Herrera wrote:
> Here's v8, which addresses all your comments except the doc updates. I
> added a few more tests, too. Thanks for the review! I intend to commit
> this shortly, probably not before Friday to give some more time for
> others to review/comment.
Looks good,
Hi Michael,
On 3/17/18 5:34 PM, Michael Banck wrote:
>
> On Fri, Mar 09, 2018 at 10:35:33PM +0100, Michael Banck wrote:
>
> I think most people (including those I had off-list discussions about
> this with) were of the opinion that such an option should be there, so I
> added an additional optio
Daniel Gustafsson writes:
> [ errdetail_hint_style_v2.patch ]
I started going through this in more detail, and I see that a significant
chunk of the changes are to put two spaces not one between sentences in
errdetail/errhint messages. This is per our style guideline:
Detail and hint messag
Hi!
Patch looks resonable, but I see some place to improvement:
spg_text_leaf_consistent() only needs to check with text_startswith() if
reconstucted value came to leaf consistent is shorter than given prefix. For
example, if level >= length of prefix then we guarantee that fully reconstracted
Hi
2018-03-22 16:30 GMT+01:00 Daniel Verite :
> David Steele wrote:
>
> > Do you know when you'll have an updated patch that addresses the minor
> > issues brought up in review and the concern above?
>
> Here's an update addressing the issues discussed:
>
> - fieldsep and recordsep are us
Hi,
The patch looks good to me - certainly in the sense that I haven't found
any bugs during the review. I do have a couple of questions and comments
about possible improvements, though. Some of this may be a case of
bike-shedding or simply because I've not looked as SPI/plpgsql before.
1) plpgs
David Steele wrote:
> Do you know when you'll have an updated patch that addresses the minor
> issues brought up in review and the concern above?
Here's an update addressing the issues discussed:
- fieldsep and recordsep are used, no more fieldsep_csv
- the command line option is --csv w
On Wed, Mar 21, 2018 at 9:51 PM, Alexander Korotkov <
a.korot...@postgrespro.ru> wrote:
> On Thu, Mar 8, 2018 at 7:13 PM, Anastasia Lubennikova <
> a.lubennik...@postgrespro.ru> wrote:
>
>> 06.03.2018 11:52, Thomas Munro:
>>
>>> On Wed, Jan 31, 2018 at 3:09 AM, Anastasia Lubennikova
>>> wrote:
>>
On 3/22/18, Tom Lane wrote:
> I don't really think it's legal C; I'd rather write BKI_DEFAULT('\054').
Okay, I'll do that.
>> Were you thinking of this comment in
>> pg_attribute.h? We use the double-quoted empty string for postgres.bki
>> and change it to '\0' for schemapg.h.
>
>> /* One of th
On Wed, Mar 21, 2018 at 11:43 PM, Michael Paquier wrote:
> On Wed, Mar 07, 2018 at 05:06:59PM -0500, Robert Haas wrote:
>> TBH I find that Homebrew example pretty odd. I would understand
>> installing each major release in a version directory, but putting
>> every point release in a different ver
On 3/22/18, Alvaro Herrera wrote:
> how about letting the line go long, with the comment at the right of
> each definition, with one blank line between struct members, as in the
> sample below? You normally don't care that these lines are too long
> since you seldom edit them -- one mostly adds o
Alvaro Herrera writes:
> how about letting the line go long, with the comment at the right of
> each definition, with one blank line between struct members, as in the
> sample below?
> NameDataproname;/* procedure name */
> Oid pronamespace BKI_DEFAULT(PGNSP); /* OID
John Naylor writes:
>> On 3/21/18, Tom Lane wrote:
>>> I've got mixed feelings about the whitespace lines between fields.
> I've attached an earlier version of pg_proc.h with both formats as I
> understand them. I turned a couple comments into multi-line comments
> to demonstrate. I think withou
Thank you, pushed
Fabien COELHO wrote:
Hello Teodor,
Patch seems usefull and commitable except comments in conditional.[ch]. I'd
like to top/header comment in each file more detailed and descriptive. As for
now it mentions only psql usage without explaining how it is basic or common.
Indee
John Naylor writes:
> On 3/22/18, Tom Lane wrote:
>> While I'm thinking of it --- I noticed one or two places where you
>> had "BKI_DEFAULT(\0)".
> Hmm, I only see this octal in pg_type.h
> chartypdelim BKI_DEFAULT(\054);
Sorry, I was going by memory rather than looking at the code.
>
John Naylor wrote:
> I've attached an earlier version of pg_proc.h with both formats as I
> understand them. I turned a couple comments into multi-line comments
> to demonstrate. I think without spaces it's just as hard to read as
> with multiple annotations. I'd vote for spaces, but then again I'
I am extending phrase operator is such way that it will have
syntax that means from n to m words, so I will use such syntax ()
further. I found that a AROUND(N) b is exactly the same as a <-N,N> b
and it can be replaced while parsing. So, what do you think of such
idea? In this patch I have no
On 3/22/18, Tom Lane wrote:
> Looking at this again, I think a big chunk of the readability problem here
> is just from the fact that we have long, similar-looking lines tightly
> packed. If it were reformatted to have comment lines and whitespace
> between, it might not look nearly as bad.
>
...
Hi
2018-03-21 8:18 GMT+01:00 Pavel Stehule :
>
>
> 2018-03-20 17:31 GMT+01:00 Peter Eisentraut com>:
>
>> On 3/16/18 06:29, Pavel Stehule wrote:
>> > attached patch fixes it
>>
>> The fix doesn't seem to work for LANGUAGE SQL procedures. For example:
>>
>> CREATE PROCEDURE ptest5(a int, b int D
On Sat, Mar 17, 2018 at 10:34 PM, Michael Banck
wrote:
> Hi,
>
> On Fri, Mar 09, 2018 at 10:35:33PM +0100, Michael Banck wrote:
> > Possibly open questions:
> >
> > 1. I have not so far changed the replication protocol to make verifying
> > checksums optional. I can go about that next if the cons
I wrote:
> On 3/21/18, Tom Lane wrote:
>> I've got mixed feelings about the whitespace lines between fields. They
>> seem like they are mostly bulking up the code and we could do without
>> 'em.
>> On the other hand, pgindent will insist on putting one before any
>> multi-line field comment, and
John Naylor writes:
> On 3/21/18, Tom Lane wrote:
>> regproc aggmtransfn BKI_DEFAULT(-) BKI_LOOKUP(pg_proc);
>> regproc aggminvtransfn BKI_DEFAULT(-) BKI_LOOKUP(pg_proc);
>> regproc aggmfinalfn BKI_DEFAULT(-) BKI_LOOKUP(pg_proc);
>> I'm not sure if there's anything muc
Hi David,
I'd like to take over from Victor. I'll post a revised version of the
patch in a couple of days.
--
Dmitry Ivanov
Postgres Professional: http://www.postgrespro.com
The Russian Postgres Company
Michael Paquier writes:
> The last complain on the matter I can find actually involves the same
> people as this thread :)
> https://www.postgresql.org/message-id/54DE457F.2090206%40gmx.net
> So the patch should be marked as rejected or at least returned with
> feedback?
IMO, changing this behav
If you want to know how PostgreSQL compares to other databases, or are
looking for ideas on areas to improve, the jOOQ blog looks like a good
resource: https://blog.jooq.org/. jOOQ is a java library that provides a
database-agnostic way to access many different types of databases. I know
it does s
Amit Langote writes:
> I too wasn't sure if the patch's modifications to
> operator_predicate_proof() led to correct handling for the case where both
> clause_const and pred_const are both NULL consts. ISTM that the result in
> that case becomes what operator_same_subexprs_proof() would return fo
On 3/21/18 10:59 PM, Amit Langote wrote:
> On 2018/03/21 23:31, David Steele wrote:
>> Hi Amit,
>>
>> On 3/6/18 9:44 AM, David Steele wrote:
>>> On 3/2/18 2:27 AM, Amit Langote wrote:
On 2018/03/02 15:58, Andres Freund wrote:
> On 2018-02-02 17:00:24 -0500, Tom Lane wrote:
>> Peter Eis
On Thu, Mar 22, 2018 at 4:32 AM, Dmitry Dolgov <9erthali...@gmail.com> wrote:
>> On 12 March 2018 at 06:00, Ashutosh Bapat
>> wrote:
>> Thanks for the note. Here are rebased patches.
>
> Since I started to look at this patch, I can share few random notes (although
> it's not a complete review, I'
Hello,
My question is more as there are so many developments arround
pg_stat_statements (see the list at the end of the initial post):
What is the roadmap for its design ?
None? As for any feature, some people may have some plans, that they may
end up developing or not. If developed, it ma
On Mon, Mar 19, 2018 at 8:45 AM, Kyotaro HORIGUCHI <
horiguchi.kyot...@lab.ntt.co.jp> wrote:
> At Mon, 19 Mar 2018 11:12:58 +0900, Masahiko Sawada
> wrote in ail.com>
> > require the bulk-delete method of scanning whole index and of logging
> > WAL. But it leads some extra overhead. With this pa
On Mon, Mar 19, 2018 at 5:12 AM, Masahiko Sawada
wrote:
> On Wed, Mar 14, 2018 at 9:25 PM, Alexander Korotkov
> wrote:
> > On Wed, Mar 14, 2018 at 7:40 AM, Masahiko Sawada
> > wrote:
> >>
> >> On Sat, Mar 10, 2018 at 3:40 AM, Alexander Korotkov
> >> wrote:
> >> > On Fri, Mar 9, 2018 at 3:12 PM
On Thu, Mar 22, 2018 at 1:15 AM, Peter Geoghegan wrote:
>
> >
> >
> > No, it did not. We only support VALUES clause with INSERT action.
>
> But can't you have a subselect in the VALUES()? Support for subselects
> seems like a totally distinct thing to the restriction that only a
> (single row) VA
Hello.
At Fri, 12 Jan 2018 10:12:35 +1100, Vaishnavi Prabakaran
wrote in
> Corrected compilation error in documentation portion of patch with latest
> postgres code. Attached the corrected patch.
My understanding of this patch is that it intends to do the
following things without changing the
Thank you Fabien.
My question is more as there are so many developments arround
pg_stat_statements (see the list at the end of the initial post):
What is the roadmap for its design ?
Could a PLANID column be added to help new developments working on plans and
parameters ?
Could all the new
On Thu, Mar 22, 2018 at 3:01 PM, Amit Langote wrote:
>
> >
> > Why do we need to pin the descriptor? If we do need, why don't we need
> > corresponding ReleaseTupDesc() call?
>
> PinTupleDesc was added in the patch as Alvaro had submitted it upthread,
> which it wasn't clear to me either why it w
On Wed, Mar 21, 2018 at 12:00:52PM +0300, Arthur Zakirov wrote:
> On Tue, Mar 20, 2018 at 09:30:15PM +0100, Tomas Vondra wrote:
> > I wonder if these restrictions needed? I mean, why not to allow setting
> > max_shared_dictionaries_size below the size of loaded dictionaries?
> >
> > Of course, on
On Thu, Mar 22, 2018 at 10:06 AM, Ashutosh Bapat <
ashutosh.ba...@enterprisedb.com> wrote:
> On Thu, Mar 22, 2018 at 3:26 AM, Robert Haas
> wrote:
> >
> > Is there a good reason not to use input_rel->relids as the input to
> > fetch_upper_rel() in all cases, rather than just at subordinate
> > le
On 2018/03/21 23:00, Tom Lane wrote:
> Emre Hasegeli writes:
>> I am not sure if we are covering the case when clause_const and
>> pred_const are both NULL. In this case, we should be able to return
>> true only by checking op_strict(pred_op) or maybe even without
>> checking that. Am I mistaken
On Thu, Mar 22, 2018 at 3:26 AM, Robert Haas wrote:
> On Wed, Mar 21, 2018 at 11:33 AM, Jeevan Chalke
> wrote:
> > Let me try to explain this:
> > 1. GROUPING_CAN_PARTITIONWISE_AGG
> > 2. extra->is_partial_aggregation
> > 3. extra->perform_partial_partitionwise_aggregation
>
> Please find attach
On 19 March 2018 at 16:59, John Naylor wrote:
> On 3/19/18, Dean Rasheed wrote:
>> As promised, here is a new patch, with comment updates, per John and
>> Tomas' suggestions, plus the continuity correction, which seemed just
>> about worthwhile.
>
> Great. I'm happy with the behavior of the patch
On 21.03.2018 20:30, Konstantin Knizhnik wrote:
On 01.03.2018 23:15, Andres Freund wrote:
Hi,
This patch seems like quite a good improvement. One thing I've not
really looked at but am slightly concerned in passing: Are there cases
where we now would do a lot of predicate pruning work even
Fujita-san, Pavan,
Thank you both for reviewing. Replying to both emails here.
On 2018/03/20 20:53, Etsuro Fujita wrote:
> Here are comments on executor changes in (the latest version of) the patch:
>
> @@ -421,8 +424,18 @@ ExecInsert(ModifyTableState *mtstate,
> ItemPointerData co
Hello,
As a new user of PostgreSQL, I have started using pg_stat_statements, and
was pleased but a little surprised:
First of all, the normalized form of the query string makes it impossible to
be used in EXPLAIN commands.
Yes, because of the normalization.
Second, normalized constants and
On 3/21/18, Tom Lane wrote:
> John Naylor writes:
>> [ v11-bootstrap-data-conversion.tar.gz ]
>
> I've done a round of review work on this, focusing on the Makefile
> infrastructure. I found a bunch of problems with parallel builds and
> VPATH builds, which are addressed in the attached incremen
Right now we are purging old LO objects because our production system run
out of memory
Mem: 41154296k total, 40797560k used, 356736k free, 15748k buffers
Swap: 16777208k total, 1333260k used, 15443948k free, 35304844k cached
SELECT count(*) FROM pg_largeobject;
count
--
52614842
(1 row)
Melanie Plageman wrote:
> Contents & Purpose
> ==
>
> This patch removes any additional columns in the DISTINCT clause when the
> table's primary key columns are entirely present in the DISTINCT clause. This
> optimization works because the PK columns functionally determine the oth
On 21 March 2018 at 12:23, Pavan Deolasee wrote:
> Fixed
Looks like that this completes all outstanding items with the MERGE code.
I'm now proposing that I move to commit this, following my own final
review, on Tues 27 Mar in 5 days time, giving time for cleanup of
related issues.
If there are
On 21 March 2018 at 19:45, Peter Geoghegan wrote:
>>> * We never actually get around to saying that MERGE is good with bulk
>>> loading, ETL, and so on. I think that we should remark on that in
>>> passing.
>>
>>
>> Suggestion?
>
> How about adding this sentence after "MERGE ... a task that would
Hi,
Am Donnerstag, den 22.03.2018, 10:33 +0900 schrieb Michael Paquier:
> Hence, is there any objection to mark this patch as returned with
> feedback?
I've done so now.
Cheers,
Michael
--
Michael Banck
Projektleiter / Senior Berater
Tel.: +49 2166 9901-171
Fax: +49 2166 9901-100
Email: m
Patch isn't applyed cleanly anymore.
Indeed. Here is a rebase. All pgbench patches conflict about test cases.
--
Fabien.diff --git a/doc/src/sgml/ref/pgbench.sgml b/doc/src/sgml/ref/pgbench.sgml
index f07ddf1..e4582bf 100644
--- a/doc/src/sgml/ref/pgbench.sgml
+++ b/doc/src/sgml/ref/pgbench.s
96 matches
Mail list logo