Re: [HACKERS] proposal: schema variables

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 >>

Re: [HACKERS] MERGE SQL Statement for PG11

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

Re: Re: csv format for psql

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

Re: Faster inserts with mostly-monotonically increasing values

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

Re: [PoC PATCH] Parallel dump to /dev/null

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:

Re: [HACKERS] MERGE SQL Statement for PG11

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

Re: [HACKERS] why not parallel seq scan for slow functions

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

Re: [HACKERS] taking stdbool.h into use

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,

Re: ON CONFLICT DO UPDATE for partitioned tables

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

Re: [HACKERS] taking stdbool.h into use

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

Re: [HACKERS] MERGE SQL Statement for PG11

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

Re: [HACKERS] MERGE SQL Statement for PG11

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

bugfifx: a minor mistake in brin_inclusion.c comment

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

Re: Using base backup exclusion filters to reduce data transferred with pg_rewind

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

Re: TOAST table created for partitioned tables

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

Re: Typo with pg_multixact/offset in multixact.c

On Thu, Mar 22, 2018 at 01:36:59PM -0400, Robert Haas wrote: > Committed. Thanks. -- Michael signature.asc Description: PGP signature

Re: Removing useless DISTINCT clauses

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

Re: Faster inserts with mostly-monotonically increasing values

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

Re: [HACKERS] MERGE SQL Statement for PG11

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

Re: [HACKERS] MERGE SQL Statement for PG11

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. > >

Re: [HACKERS] MERGE SQL Statement for PG11

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

Re: [PATCH] Verify Checksums during Basebackups

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

Re: Error detail/hint style fixup

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.

Re: [HACKERS] Surjective functional indexes

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(),

Re: [HACKERS] Surjective functional indexes

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,

Re: Re: Re: reorganizing partitioning code

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

Re: Re: Re: reorganizing partitioning code

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

Re: parallel append vs. simple UNION ALL

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

Re: [HACKERS] VACUUM and ANALYZE disagreeing on what reltuples means

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

Re: [HACKERS] VACUUM and ANALYZE disagreeing on what reltuples means

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

Re: Re: csv format for psql

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

Re: [HACKERS] Add support for tuple routing to foreign partitions

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

Re: Error detail/hint style fixup

> 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

Re: Re: csv format for psql

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,

Re: [FEATURE PATCH] pg_stat_statements with plans (v02)

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, -

Re: TOAST table created for partitioned tables

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

Re: Re: csv format for psql

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

Re: Typo with pg_multixact/offset in multixact.c

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

Re: Changing default value of wal_sync_method to open_datasync on Linux

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

Re: [HACKERS] VACUUM and ANALYZE disagreeing on what reltuples means

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

Re: Updating parallel.sgml's treatment of parallel joins

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

Re: pgstat_report_activity() and parallel CREATE INDEX (was: Parallel index creation & pg_stat_activity)

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

Re: [HACKERS] Partition-wise aggregation/grouping

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

Re: [HACKERS] Surjective functional indexes

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

Re: FOR EACH ROW triggers on partitioned tables

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 > >

Re: Using base backup exclusion filters to reduce data transferred with pg_rewind

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

Re: FOR EACH ROW triggers on partitioned tables

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

Re: [PATCH] Verify Checksums during Basebackups

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

Re: Error detail/hint style fixup

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:

Re: Prefix operator for text and spgist support

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

Re: Re: csv format for psql

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: > > -

Re: PL/pgSQL nested CALL with transactions

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)

Re: Re: csv format for psql

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

Re: WIP: Covering + unique indexes.

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 >>>

Re: WIP: a way forward on bootstrap data

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

Re: faster testing with symlink installs

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

Re: WIP: a way forward on bootstrap data

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

Re: pgbench - add \if support

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.

Re: WIP: a way forward on bootstrap data

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

Re: WIP: a way forward on bootstrap data

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

Re: [HACKERS] new function for tsquery creartion

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

Re: WIP: a way forward on bootstrap data

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

Re: missing support of named convention for procedures

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.

Re: [PATCH] Verify Checksums during Basebackups

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

Re: WIP: a way forward on bootstrap data

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 >>

Re: WIP: a way forward on bootstrap data

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);

Re: new function for tsquery creartion

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

Re: faster testing with symlink installs

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?

FYI: jOOQ blog

​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

Re: constraint exclusion and nulls in IN (..) clause

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

Re: Boolean partitions syntax

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

Re: [HACKERS] advanced partition matching algorithm for partition-wise join

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

RE: pg_stat_statements HLD for futur developments

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

Re: [HACKERS] GUC for cleanup indexes threshold.

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

Re: [HACKERS] GUC for cleanup indexes threshold.

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

Re: [HACKERS] MERGE SQL Statement for PG11

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 >

RE: pg_stat_statements HLD for futur developments

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

Re: ON CONFLICT DO UPDATE for partitioned tables

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

Re: [PROPOSAL] Shared Ispell dictionaries

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

Re: [HACKERS] Partition-wise aggregation/grouping

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

Re: constraint exclusion and nulls in IN (..) clause

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

Re: [HACKERS] Partition-wise aggregation/grouping

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.

Re: MCV lists for highly skewed distributions

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. > >

Re: [HACKERS] Secondary index access optimizations

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

Re: ON CONFLICT DO UPDATE for partitioned tables

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

Re: pg_stat_statements HLD for futur developments

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

Re: WIP: a way forward on bootstrap data

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,

Re: Hash join in SELECT target list expression keeps consuming memory

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)

Re: Removing useless DISTINCT clauses

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

Re: [HACKERS] MERGE SQL Statement for PG11

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

Re: [HACKERS] MERGE SQL Statement for PG11

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

Re: [PoC PATCH] Parallel dump to /dev/null

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:

Re: pgbench randomness initialization

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 +++

Re: Faster inserts with mostly-monotonically increasing values

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 would > need some cleanup. > Here is an