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
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
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
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
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
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
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 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.
>
...
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
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'
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.
>
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/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
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
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
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, 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 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:
>>
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
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
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!
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
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 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
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,
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
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
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
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
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 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
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 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
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
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 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,
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,
- .
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
> 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
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
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
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
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
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 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
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
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
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
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
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
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
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 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 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 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 01:36:59PM -0400, Robert Haas wrote:
> Committed.
Thanks.
--
Michael
signature.asc
Description: PGP signature
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 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
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
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
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
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 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/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 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 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 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 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?
>>>
>
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: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-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
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
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
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
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
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
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)
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
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
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
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
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 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 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 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 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 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
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
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
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
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 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
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 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'
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
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
96 matches
Mail list logo
