Re: Offline enabling/disabling of data checksums

Hi, On 2019-03-20 07:55:39 +0100, Fabien COELHO wrote: > > And you're basically adding it because Fabien doesn't like > > postmaster.pid and wants to invent another lockout mechanism in this > > thread. > > I did not suggest to rename the control file, but as it is already done by > another comma

Re: Transaction commits VS Transaction commits (with parallel) VS query mean time

Hi Haribabu, The latest patch fails while applying header files part. Kindly rebase. The patch looks good to me. However, I wonder what are the other scenarios where xact_commit is incremented because even if I commit a single transaction with your patch applied the increment in xact_commit is >

PostgreSQL pollutes the file system

PostgreSQL pollutes the file system with lots of binaries that it is not obvious that they belong to PostgreSQL. Such as "/usr/bin/createdb", etc. It would be better if these files were renamed to be prefixed with pg_, such as pg_createdb. Or even better postgresql-createdb then be reachable by t

Re: GSOC Application

Thank you for your response. On Wed, Mar 13, 2019 at 6:02 PM Andrey Borodin wrote: > Hi, Pavan! > > > 12 марта 2019 г., в 12:01, pavan gudivada > написал(а): > > > > I am Pavan_Gudivada.I have good knowledge in HTML, > CSS,JAVASCRIPT,PYTHON and SQL.After i know about PostgreSQL and its > cont

[GSoC] application ideas

Greetings, i am interested in databases and would like to make a contribution to thePostgreSQL by participating in GSoC 2019. Currently i am studying in HSE[1],doing last year of master's program that mostly build on top of collaborationwith ISP RAS[2]. In the previous year i have been working on l

Re: REINDEX CONCURRENTLY 2.0

On 2019-03-15 22:32, Michael Banck wrote: > I had a quick look at some of the comments and noticed some possible > nitpicky-level problems: Thanks, I've integrated these changes into my local branch. -- Peter Eisentraut http://www.2ndQuadrant.com/ PostgreSQL Development, 24x7 Suppor

Re: Offline enabling/disabling of data checksums

Hallo Andres, [...] pg_upgrade in link mode intentionally wants to *permanently* disable a cluster. And it explicitly writes a log message about it. That's not a case to draw inferrence for this case. Ok. My light knowledge of pg_upgrade inner working does not extend to this level of prec

Re: [HACKERS] WAL logging problem in 9.4.3?

Thank you for reviewing! At Sun, 10 Mar 2019 19:27:08 -0700, Noah Misch wrote in <20190311022708.ga2189...@rfd.leadboat.com> > This has been waiting for a review since October, so I reviewed it. The code > comment at PendingRelSync summarizes the design well, and I like that design. It is Mich

Re: speeding up planning with partitions

Imai-san, On 2019/03/20 12:15, Imai, Yoshikazu wrote: > Here the details. > > [creating partitioned tables (with 1024 partitions)] > drop table if exists rt; > create table rt (a int, b int, c int) partition by range (a); > \o /dev/null > select 'create table rt' || x::text || ' partition of rt f

RE: speeding up planning with partitions

Amit-san, On Wed, Mar 20, 2019 at 8:21 AM, Amit Langote wrote: > On 2019/03/20 12:15, Imai, Yoshikazu wrote: > > Here the details. > > > > [creating partitioned tables (with 1024 partitions)] drop table if > > exists rt; create table rt (a int, b int, c int) partition by range > > (a); \o /dev/nul

Re: Transaction commits VS Transaction commits (with parallel) VS query mean time

On Sun, Feb 10, 2019 at 10:54 AM Haribabu Kommi wrote: > On Sat, Feb 9, 2019 at 4:07 PM Amit Kapila wrote: >> >> I don't think so. It seems to me that we should consider it as a >> single transaction. Do you want to do the leg work for this and try >> to come up with a patch? On a quick look,

Re: Problem with default partition pruning

Hi Thibaut, On 2019/03/19 23:58, Thibaut Madelaine wrote: > I kept on testing with sub-partitioning. Thanks. > I found a case, using 2 default partitions, where a default partition is > not pruned: > > -- > > create table test2(id int, val text) partition by range (id); > create tab

Re: speeding up planning with partitions

Imai-san, On 2019/03/20 17:36, Imai, Yoshikazu wrote: > On Wed, Mar 20, 2019 at 8:21 AM, Amit Langote wrote: >> On 2019/03/20 12:15, Imai, Yoshikazu wrote: >>> [select1024.sql] >>> \set a random (1, 1024) >>> select * from rt where a = :a; >>> >>> [pgbench] >>> pgbench -n -f select1024.sql -T 60 >

Re: BUG #15668: Server crash in transformPartitionRangeBounds

Hi, On 2019/03/20 11:07, Michael Paquier wrote: > On Thu, Mar 14, 2019 at 01:23:08PM +0900, Michael Paquier wrote: >> I actually think that what you propose here makes more sense than what >> HEAD does because the most inner expression gets evaluated first. >> This for example generates the same e

Re: BUG #15668: Server crash in transformPartitionRangeBounds

On Wed, Mar 20, 2019 at 06:07:23PM +0900, Amit Langote wrote: > because we can notice the aggregate before we look into its arguments. > Maybe, we should move the error-checking switch to a point before checking > the arguments? That looks slightly more drastic change to make though. Yeah, I thin

Re: Offline enabling/disabling of data checksums

Michaël-san, In short, you keep the main feature with: - No tweaks with postmaster.pid. - Rely just on the control file indicating an instance shutdown cleanly. - No tweaks with the system ID. - No renaming of the control file. Hmmm… so nothing:-) I think that this feature is useful, in comp

Re: Special role for subscriptions

Hi! > Currently, user with pg_subscription_users can create subscription into any > system table, can't they? > We certainly need to change it to more secure way. No, you can't add system tables to publication. In new patch i add privileges checks on target table, non superuser can't create/ref

RE: speeding up planning with partitions

Amit-san, On Wed, Mar 20, 2019 at 9:07 AM, Amit Langote wrote: > On 2019/03/20 17:36, Imai, Yoshikazu wrote: > > On Wed, Mar 20, 2019 at 8:21 AM, Amit Langote wrote: > >> On 2019/03/20 12:15, Imai, Yoshikazu wrote: > >>> [select1024.sql] > >>> \set a random (1, 1024) > >>> select * from rt where a

Re: PostgreSQL pollutes the file system

On 3/19/19 11:19 AM, Fred .Flintstone wrote: PostgreSQL pollutes the file system with lots of binaries that it is not obvious that they belong to PostgreSQL. Such as "/usr/bin/createdb", etc. It would be better if these files were renamed to be prefixed with pg_, such as pg_createdb. Or even be

Re: Re: Reporting script runtimes in pg_regress

Hi Christophe, On 3/8/19 5:12 PM, Alvaro Herrera wrote: On 2019-Mar-08, Christoph Berg wrote: Re: Peter Eisentraut 2019-03-08 <3eb194cf-b878-1f63-8623-6d6add0ed...@2ndquadrant.com> On 2019-02-21 10:37, Christoph Berg wrote: diff --git a/src/test/regress/pg_regress.c b/src/test/regress/pg_re

Re: Re: COPY FREEZE and setting PD_ALL_VISIBLE/visibility map bits

Hi Pavan, On 3/14/19 2:20 PM, Masahiko Sawada wrote: On Thu, Mar 14, 2019 at 5:17 PM Pavan Deolasee wrote: Ok. I will run some tests. But please note that this patch is a bug fix to address the performance issue that is caused by having to rewrite the entire table when all-visible bit is se

Re: Re: [RFC] [PATCH] Flexible "partition pruning" hook

Hi Peter, On 2/28/19 10:36 PM, Mike Palmiotto wrote: On Wed, Feb 27, 2019 at 12:36 PM Peter Eisentraut wrote: To rephrase this: You have a partitioned table, and you have a RLS policy that hides certain rows, and you know based on your business logic that under certain circumstances entire pa

Re: selecting from partitions and constraint exclusion

On Wed, 20 Mar 2019 at 17:37, Amit Langote wrote: > That's because get_relation_constraints() no longer (as of PG 11) includes > the partition constraint for SELECT queries. But that's based on an > assumption that partitions are always accessed via parent, so partition > pruning would make loadi

Re: Re: Planning counters in pg_stat_statements (using pgss_store)

Hi PAscal, On 2/15/19 11:32 AM, Sergei Kornilov wrote: Hi  +#define PG_STAT_STATEMENTS_COLS_V1_4 25 I thought it was needed when adding new columns, isn't it ? Yes, this is needed. I mean it should be PG_STAT_STATEMENTS_COLS_V1_8: because such change was made for 1.8 pg_stat_statements v

Re: Re: query logging of prepared statements

Hi Justin, On 3/5/19 2:30 PM, Arthur Zakirov wrote: On 04.03.2019 21:31, Justin Pryzby wrote: It wasn't intentional.  Find attached v3 patch which handles that case, by removing the 2nd call to errdetail_execute() ; since it's otherwise unused, so remove that function entirely. Thank you.

Re: Re: A separate table level option to control compression

Hi Pavan, On 3/12/19 4:38 PM, Andrew Dunstan wrote: On 3/11/19 2:23 AM, Masahiko Sawada wrote: I like this idea. The patch seems to need update the part describing on-disk toast storage in storage.sgml. Yeah. Meanwhile, here's a rebased version of the patch to keep the cfbot happy. Looks

Re: PostgreSQL pollutes the file system

On Wed, Mar 20, 2019 at 11:06 AM Andreas Karlsson wrote: > On 3/19/19 11:19 AM, Fred .Flintstone wrote: > > PostgreSQL pollutes the file system with lots of binaries that it is > > not obvious that they belong to PostgreSQL. > > > > Such as "/usr/bin/createdb", etc. > > > > It would be better if

Re: Re: Psql patch to show access methods info

Hi Sergey, On 3/8/19 8:52 AM, Kyotaro HORIGUCHI wrote: At Mon, 10 Dec 2018 19:38:39 +0300, s.cherkas...@postgrespro.ru wrote in <70e94e339dd0fa2be5d3eebec68da...@postgrespro.ru> Here are some fixes. But I'm not sure that the renaming of columns for the '\dAp' command is sufficiently laconic a

Re: BUG #15572: Misleading message reported by "Drop function operation" on DB with functions having same name

Thanks for reviewing this. On Wed, 20 Mar 2019 at 04:31, Pavel Stehule wrote: > I propose maybe more strongly comment fact so noError is applied only on "not > found" event. In other cases, this flag is ignored and error is raised > immediately there. I think so it is not good enough commented

Re: Should we add GUCs to allow partition pruning to be disabled?

On Thu, 14 Mar 2019 at 02:10, Robert Haas wrote: > > On Tue, Mar 12, 2019 at 7:28 PM David Rowley > wrote: > > I think I've done that in the attached patch. > > Cool, thanks. Just so I don't forget about this, I've added it to the July 'fest. https://commitfest.postgresql.org/23/2065/ -- Dav

Re: Removing unneeded self joins

On 3/14/19 14:21, David Rowley wrote: What do you think? Let's recap the conditions when we can remove a self-join. It is when for each outer row, 1) at most one inner row matches the join clauses, and 2) it is the same row as the outer one. I'm not sure what (2) means precisely in a gener

Re: Add exclusive backup deprecation notes to documentation

On 3/8/19 6:08 AM, Magnus Hagander wrote: On Thu, Mar 7, 2019 at 5:35 PM Michael Paquier > wrote: On Thu, Mar 07, 2019 at 11:33:20AM +0200, David Steele wrote: > OK, here's a new version that splits the deprecation notes from the > discussion of risks. 

Re: Offline enabling/disabling of data checksums

On Wed, Mar 20, 2019 at 10:38:36AM +0100, Fabien COELHO wrote: > Hmmm… so nothing:-) The core of the feature is still here, fortunately. > I think that a clear warning not to run any cluster command in parallel, > under pain of possible cluster corruption, and possibly other caveats about > repli

Re: Add exclusive backup deprecation notes to documentation

On Wed, Mar 20, 2019 at 04:29:35PM +0400, David Steele wrote: > Please note that there have been objections to the patch later in this > thread by Peter and Robert. I'm not very interested in watering down the > documentation changes as Peter suggests, but I think at the very least we > should com

Re: Re: query logging of prepared statements

Hi, On Wed, Mar 20, 2019 at 02:46:00PM +0400, David Steele wrote: > >I perfectly understand your use case. I agree, it is duplicated. But I > >think some people may want to see it at every EXECUTE, if they don't want > >to grep for the prepared statement body which was logged earlier. > > > >I thi

Re: PostgreSQL pollutes the file system

It seems nothing came out of the discussion in 2008. I feel the topic should be revisited. I am in favor of doing so too. The deprecation cycle could involve symlinks for a brief period of time or a couple of versions. Yes, the wrapper script approach is used by Git as well as the "dotnet" comman

Re: [GSoC] application ideas

Excuse me for the previous letter, should be fixed now by using simple html. --- Greetings, i am interested in databases and would like to make a contribution to the PostgreSQL by participating in GSoC 2019. Currently i am studying in HSE[1], doing last year of master's program that mostly build

Re: Add exclusive backup deprecation notes to documentation

On Mon, Mar 18, 2019 at 1:33 PM Peter Eisentraut < peter.eisentr...@2ndquadrant.com> wrote: > On 2019-03-07 10:33, David Steele wrote: > > On 3/1/19 3:14 PM, Laurenz Albe wrote: > I think it would be helpful to frame the documentation in a way to > suggest that the nonexclusive mode is more for au

Re: Special role for subscriptions

On Wed, Mar 20, 2019 at 5:39 AM Evgeniy Efimkin wrote: > Hi! > > Currently, user with pg_subscription_users can create subscription into any > > system table, can't they? > > We certainly need to change it to more secure way. > No, you can't add system tables to publication. In new patch i add pr

Re: PostgreSQL pollutes the file system

Another pattern is to have a separate bin path for various software packages:  /opt/postgres/bin  for example. That doesn't directly answer "what is createdb?" but it does give a quicker indication via the 'which' command. On 3/20/19 5:43 AM, Fred .Flintstone wrote: It seems nothing came o

Re: PostgreSQL pollutes the file system

Chris Travers writes: > On Wed, Mar 20, 2019 at 11:06 AM Andreas Karlsson wrote: >> On 3/19/19 11:19 AM, Fred .Flintstone wrote: >>> It would be better if these files were renamed to be prefixed with >>> pg_, such as pg_createdb. >>> Or even better postgresql-createdb then be reachable by through

Re: speeding up planning with partitions

Hi, On 3/19/19 11:15 PM, Imai, Yoshikazu wrote: Here the details. [creating partitioned tables (with 1024 partitions)] drop table if exists rt; create table rt (a int, b int, c int) partition by range (a); \o /dev/null select 'create table rt' || x::text || ' partition of rt for values from ('

Re: Add exclusive backup deprecation notes to documentation

On Wed, Mar 20, 2019 at 9:00 AM Michael Paquier wrote: > On Wed, Mar 20, 2019 at 04:29:35PM +0400, David Steele wrote: > > Please note that there have been objections to the patch later in this > > thread by Peter and Robert. I'm not very interested in watering down the > > documentation changes

Re: PostgreSQL pollutes the file system

>>> This topic has been discussed before e.g. in 2008 in >>> https://www.postgresql.org/message-id/47EA5CC0.8040102%40sun.com and >>> also more recently but I cannot find it in the archives right now. > > And also before that, eg > https://www.postgresql.org/message-id/flat/199910091253.IAA10670%4

Re: Automated way to find actual COMMIT LSN of subxact LSN

> > If recovery_target_inclusive were able to take the third value > "xact", is it exactly what you want? > > And is it acceptable? > Yes, that would be exactly what I would want. It would work to have a 3rd value for recovery_target_inclusive, although perhaps it's debatable that instead, it sho

Re: Built-in connection pooler

New version of the patch (rebased + bug fixes) is attached to this mail. On 20.03.2019 18:32, Konstantin Knizhnik wrote: Attached please find results of benchmarking of different connection poolers. Hardware configuration:    Intel(R) Xeon(R) CPU   X5675  @ 3.07GHz    24 cores (12 phys

Re: pg_basebackup ignores the existing data directory permissions

On 2019-03-18 16:45, Robert Haas wrote: >> I'm strongly in favor of keeping initdb and pg_basebackup options >> similar and consistent. They are both ways to initialize data directories. >> >> You'll note that initdb does not behave the way you describe. It's not >> unreasonable behavior, but it'

Re: Special role for subscriptions

> 20 марта 2019 г., в 21:46, Robert Haas написал(а): > > On Wed, Mar 20, 2019 at 5:39 AM Evgeniy Efimkin > wrote: >> Hi! >>> Currently, user with pg_subscription_users can create subscription into any >>> system table, can't they? >>> We certainly need to change it to more secure way. >> No

Re: partitioned tables referenced by FKs

On 2019-Mar-19, Alvaro Herrera wrote: > I think this is fixable by using a two-step strategy where we first > compile a list of constraints being dropped, and in the second step we > know to ignore those when checking partitions that are being dropped. > Now, maybe the order of objects visited gua

Re: pg_basebackup ignores the existing data directory permissions

On 2019-03-19 08:34, Haribabu Kommi wrote: > How about the following change? > > pg_basebackup  --> copies the contents of the src directory (with group > access)  > and even the root directory permissions. > > pg_basebackup --no-group-access   --> copies the contents of the src > directory  > (w

Re: Sparse bit set data structure

On Wed, Mar 20, 2019 at 2:10 AM Heikki Linnakangas wrote: > > On 14/03/2019 17:37, Julien Rouhaud wrote: > > > + if (newitem <= sbs->last_item) > > + elog(ERROR, "cannot insert to sparse bitset out of order"); > > > > Is there any reason to disallow inserting duplicates? AFAICT no

Re: Automated way to find actual COMMIT LSN of subxact LSN

Jeremy Finzel writes: > A related problem kind of demonstrates the same odd behavior. If you put > in recovery_target_xid to a subtransaction_id, it just skips it and > continues recovering, which really seems to be undesirable behavior. It > would be nice if that also could roll up to the next

Re: Offline enabling/disabling of data checksums

Michaël-san, I think that a clear warning not to run any cluster command in parallel, under pain of possible cluster corruption, and possibly other caveats about replication, should appear in the documentation. I still have the following extra documentation in my notes: Ok, it should have b

Re: Optimze usage of immutable functions as relation

On 11/16/18 22:03, Tom Lane wrote: A possible fix for this is to do eval_const_expressions() on function RTE expressions at this stage (and then not need to do it later), and then pull up only when we find that the RTE expression has been reduced to a single Const. Attached is a patch that doe

Re: Add exclusive backup deprecation notes to documentation

Hi Robert, On 3/20/19 6:31 PM, Robert Haas wrote: On Wed, Mar 20, 2019 at 9:00 AM Michael Paquier wrote: On Wed, Mar 20, 2019 at 04:29:35PM +0400, David Steele wrote: Please note that there have been objections to the patch later in this thread by Peter and Robert. I'm not very interested in

Re: PostgreSQL pollutes the file system

On Wed, Mar 20, 2019 at 3:19 PM Tom Lane wrote: > If we didn't pull the trigger twenty years ago, nor ten years ago, > we're not likely to do so now. Yeah, it's a mess and we'd certainly > do it differently if we were starting from scratch, but we're not > starting from scratch. There are decade

Re: PostgreSQL pollutes the file system

Em qua, 20 de mar de 2019 às 11:39, Tatsuo Ishii escreveu: > > +1. As one of third party PostgreSQL tool developers, I am afraid > changing names of PostgreSQL commands would give us lots of pain: for > example checking PostgreSQL version to decide to use command "foo" not > "pg_foo". > createdb,

Re: PostgreSQL pollutes the file system

Em qua, 20 de mar de 2019 às 14:22, Fred .Flintstone escreveu: > > Even just creating symlinks would be a welcome change. > So the real binary is pg_foo and foo is a symoblic link that points to pg_foo. > Then at least I can type pg_ and use tab auto-completion to find > everything related to Post

Re: PostgreSQL pollutes the file system

On 2019-Mar-20, Fred .Flintstone wrote: > Even just creating symlinks would be a welcome change. > So the real binary is pg_foo and foo is a symoblic link that points to pg_foo. > Then at least I can type pg_ and use tab auto-completion to find > everything related to PostgreSQL. There is merit t

Re: PostgreSQL pollutes the file system

On Wed, Mar 20, 2019 at 6:25 PM Euler Taveira wrote: > > createdb, dropdb, createuser, dropuser, reindexdb are binaries that > confuse most newbies. Which tool is theses binaries from? The names > does not give a hint. How often those confusing name tools are used? initdb is probably an order of

Re: Sparse bit set data structure

On Wed, Mar 20, 2019 at 5:20 PM Julien Rouhaud wrote: > > On Wed, Mar 20, 2019 at 2:10 AM Heikki Linnakangas wrote: > > > I'm now pretty satisfied with this. Barring objections, I'll commit this > > in the next few days. Please review, if you have a chance. > > You're defining SIMPLE8B_MAX_VALUE

Re: PostgreSQL pollutes the file system

Julien Rouhaud writes: > On Wed, Mar 20, 2019 at 6:25 PM Euler Taveira wrote: >> createdb, dropdb, createuser, dropuser, reindexdb are binaries that >> confuse most newbies. Which tool is theses binaries from? The names >> does not give a hint. How often those confusing name tools are used? > in

Re: PostgreSQL pollutes the file system

Em qua, 20 de mar de 2019 às 14:57, Tom Lane escreveu: > > We managed to get rid of createlang and droplang in v10, and there > hasn't been that much push-back about it. So maybe there could be > a move to remove createuser/dropuser? Or at least rename them to > pg_createuser and pg_dropuser. B

Re: PostgreSQL pollutes the file system

On 2019-Mar-20, Euler Taveira wrote: > Em qua, 20 de mar de 2019 às 14:57, Tom Lane escreveu: > > > > We managed to get rid of createlang and droplang in v10, and there > > hasn't been that much push-back about it. So maybe there could be > > a move to remove createuser/dropuser? Or at least re

Re: PostgreSQL pollutes the file system

On Wed, 20 Mar 2019 13:56:55 -0400 Tom Lane wrote: > Julien Rouhaud writes: > > On Wed, Mar 20, 2019 at 6:25 PM Euler Taveira > > wrote: > >> createdb, dropdb, createuser, dropuser, reindexdb are binaries that > >> confuse most newbies. Which tool is theses binaries from? The names > >> does

Re: PostgreSQL pollutes the file system

"Fred .Flintstone" writes: > Even just creating symlinks would be a welcome change. > So the real binary is pg_foo and foo is a symoblic link that points to pg_foo. > Then at least I can type pg_ and use tab auto-completion to find > everything related to PostgreSQL. You'd miss psql. I think the

Re: GiST VACUUM

On 15/03/2019 20:25, Andrey Borodin wrote: 11 марта 2019 г., в 20:03, Heikki Linnakangas написал(а): On 10/03/2019 18:40, Andrey Borodin wrote: One thing still bothers me. Let's assume that we have internal page with 2 deletable leaves. We lock these leaves in order of items on internal page.

Re: GiST VACUUM

On 15/03/2019 20:25, Andrey Borodin wrote: 11 марта 2019 г., в 20:03, Heikki Linnakangas написал(а): On 10/03/2019 18:40, Andrey Borodin wrote: One thing still bothers me. Let's assume that we have internal page with 2 deletable leaves. We lock these leaves in order of items on internal page.

Re: PostgreSQL pollutes the file system

On 3/20/19 9:32 PM, Alvaro Herrera wrote: On 2019-Mar-20, Fred .Flintstone wrote: Even just creating symlinks would be a welcome change. So the real binary is pg_foo and foo is a symoblic link that points to pg_foo. Then at least I can type pg_ and use tab auto-completion to find everything rel

Re: Feature: triggers on materialized views

On 3/15/19 8:15 PM, Mitar wrote: The only pending/unaddressed comment is about the philosophical question of what it means to be a trigger. There it seems we simply disagree with the reviewer and I do not know how to address that. I just see this as a very pragmatical feature which provides feat

Re: PostgreSQL pollutes the file system

On 3/20/19 2:08 PM, Alvaro Herrera wrote: > On 2019-Mar-20, Euler Taveira wrote: > >> Em qua, 20 de mar de 2019 às 14:57, Tom Lane escreveu: >>> >>> We managed to get rid of createlang and droplang in v10, and there >>> hasn't been that much push-back about it. So maybe there could be >>> a move

Re: PostgreSQL pollutes the file system

On 3/20/19 2:11 PM, Tom Lane wrote: > "Fred .Flintstone" writes: >> Even just creating symlinks would be a welcome change. >> So the real binary is pg_foo and foo is a symoblic link that points to >> pg_foo. >> Then at least I can type pg_ and use tab auto-completion to find >> everything related

Re: PostgreSQL pollutes the file system

On 2019-03-20 15:13:00 -0400, Jonathan S. Katz wrote: > Pardon this naive question as I have not used such systems in awhile, > but would this work on systems that do not support symlinks? We can just copy the binaries there, they're not that big anyway.

Re: PostgreSQL pollutes the file system

Hi, On 2019-03-20 15:15:02 -0400, Jonathan S. Katz wrote: > If we are evaluating this whole symlink / renaming thing, there could be > arguments for a "pgsql" alias to psql (or vice versa), but I don't think > "pg_sql" makes any sense and could be fairly confusing. I don't care much about created

Re: Feature improvement: can we add queryId for pg_catalog.pg_stat_activity view?

Hi Jim, Robert, As this is a distinct subject from adding QueryId to pg_stat_activity, would it be possible to continue the discussion "new QueryId definition" (for postgres open source software) here: https://www.postgresql.org/message-id/1553029215728-0.p...@n3.nabble.com Thanks in advance. R

Re: PostgreSQL pollutes the file system

On 3/20/19 3:19 PM, Andres Freund wrote: > Hi, > > On 2019-03-20 15:15:02 -0400, Jonathan S. Katz wrote: >> If we are evaluating this whole symlink / renaming thing, there could be >> arguments for a "pgsql" alias to psql (or vice versa), but I don't think >> "pg_sql" makes any sense and could be

RE: [survey] New "Stable" QueryId based on normalized query text

> From: "Tsunakawa, Takayuki" >> From: legrand legrand [mailto:legrand_legrand@] >> There are many projects that use alternate QueryId >> distinct from the famous pg_stat_statements jumbling algorithm. >I'd like to welcome the standard QueryID that DBAs and extension developers can depend on. >A

Re: PostgreSQL pollutes the file system

On 2019-Mar-20, Andres Freund wrote: > On 2019-03-20 15:15:02 -0400, Jonathan S. Katz wrote: > > If we are evaluating this whole symlink / renaming thing, there could be > > arguments for a "pgsql" alias to psql (or vice versa), but I don't think > > "pg_sql" makes any sense and could be fairly co

Re: reducing the footprint of ScanKeyword (was Re: Large writable variables)

Many thanks for working on this, amazing work, really nice you made it a separate reusable Perl-module. The generated hash functions reads one character at a time. I've seen a performance trick in other hash functions [1] to instead read multiple bytes in each iteration, and then handle the remain

Re: [survey] New "Stable" QueryId based on normalized query text

> From "Kyotaro HORIGUCHI-2" >>At Wed, 20 Mar 2019 00:23:30 +, "Tsunakawa, Takayuki" >>> From: legrand legrand [mailto:legrand_legrand@] >>> norm.9: comments aware >> Is this to distinguish queries that have different comments for optimizer >> hints? If yes, I agree. > Or, any means to give

Re: reducing the footprint of ScanKeyword (was Re: Large writable variables)

Joel Jacobson writes: > I've seen a performance trick in other hash functions [1] > to instead read multiple bytes in each iteration, > and then handle the remaining bytes after the loop. > [1] https://github.com/wangyi-fudan/wyhash/blob/master/wyhash.h#L29 I can't get very excited about this, se

Re: [survey] New "Stable" QueryId based on normalized query text

On Wed, Mar 20, 2019 at 8:39 PM legrand legrand wrote: > > Yes, I would like first to understand what are the main needs, I don't really see one implementation that suits every need, as probably not everyone will agree on using relation name vs fully qualified relation name for starter. The idea

Re: propagating replica identity to partitions

Unless there are any objections to fixing the REPLICA IDENTITY bug, I intend to push that tomorrow. People can continue to discuss changing the behavior of other subcommands where reasonable (OWNER TO) or even for the cases others consider not reasonable (TABLESPACE), but there is no consensus of

Re: [survey] New "Stable" QueryId based on normalized query text

Julien Rouhaud wrote > On Wed, Mar 20, 2019 at 8:39 PM legrand legrand > < > legrand_legrand@ > > wrote: >> >> Yes, I would like first to understand what are the main needs, > > I don't really see one implementation that suits every need, as > probably not everyone will agree on using relation n

Re: [survey] New "Stable" QueryId based on normalized query text

maybe this patch (with a GUC) https://www.postgresql.org/message-id/55e51c48.1060...@uptime.jp would be enough for thoses actually using a text normalization function. -- Sent from: http://www.postgresql-archive.org/PostgreSQL-hackers-f1928748.html

Re: Re: A separate table level option to control compression

Jumping in here, please be gentle. :) Contents & Purpose == This appears to be a patch to add a new table storage option similar to `toast_tuple_target` but geared toward compression. As a result, it's been named `compress_tuple_target`, and allows modifying the threshold where in

Re: [survey] New "Stable" QueryId based on normalized query text

On Wed, Mar 20, 2019 at 10:18 PM legrand legrand wrote: > > On my personal point of view, I need to get the same Queryid between (OLAP) > environments > to be able to compare Production, Pre-production, Qualif performances > (and I don't need Fully qualified relation names). Today to do that, > I'

Re: [survey] New "Stable" QueryId based on normalized query text

On Wed, Mar 20, 2019 at 10:30 PM legrand legrand wrote: > > maybe this patch (with a GUC) > https://www.postgresql.org/message-id/55e51c48.1060...@uptime.jp > would be enough for thoses actually using a text normalization function. The rest of thread raise quite a lot of concerns about the semant

Re: [survey] New "Stable" QueryId based on normalized query text

Julien Rouhaud wrote > On Wed, Mar 20, 2019 at 10:18 PM legrand legrand > < > legrand_legrand@ > > wrote: >> >> On my personal point of view, I need to get the same Queryid between >> (OLAP) >> environments >> to be able to compare Production, Pre-production, Qualif performances >> (and I don't n

Re: [survey] New "Stable" QueryId based on normalized query text

Julien Rouhaud wrote > On Wed, Mar 20, 2019 at 10:30 PM legrand legrand > < > legrand_legrand@ > > wrote: >> >> maybe this patch (with a GUC) >> https://www.postgresql.org/message-id/ > 55E51C48.1060102@ >> would be enough for thoses actually using a text normalization function. > > The rest o

Re: PostgreSQL pollutes the file system

On 3/20/19 7:08 PM, Alvaro Herrera wrote: > On 2019-Mar-20, Euler Taveira wrote: > >> Em qua, 20 de mar de 2019 às 14:57, Tom Lane escreveu: >>> >>> We managed to get rid of createlang and droplang in v10, and there >>> hasn't been that much push-back about it. So maybe there could be >>> a move

Re: [survey] New "Stable" QueryId based on normalized query text

On Wed, Mar 20, 2019 at 11:10 PM legrand legrand wrote: > > Thank you Julien for the workaround, > It is not easy to build "cross tables" in excel to join metrics per query > text ... then keep only one queryid over all environments, that's easy enough in SQL: SELECT min(queryid) OVER (partition

Re: Removing unneeded self joins

On Thu, 21 Mar 2019 at 01:20, Alexander Kuzmenkov wrote: > Let's recap the conditions when we can remove a self-join. It is when > for each outer row, 1) at most one inner row matches the join clauses, > and 2) it is the same row as the outer one. I'm not sure what (2) means > precisely in a gener

Re: PostgreSQL pollutes the file system

>> +1. As one of third party PostgreSQL tool developers, I am afraid >> changing names of PostgreSQL commands would give us lots of pain: for >> example checking PostgreSQL version to decide to use command "foo" not >> "pg_foo". >> > createdb, dropdb, createuser, dropuser, reindexdb are binaries th

Re: Offline enabling/disabling of data checksums

On Wed, Mar 20, 2019 at 05:46:32PM +0100, Fabien COELHO wrote: > I think that the motivation/risks should appear before the solution. "As xyz > ..., ...", or there at least the logical link should be outlined. > > It is not clear for me whether the following sentences, which seems specific > to "p

Re: PostgreSQL pollutes the file system

> I don't really understand what issue are we trying to solve here. > > Can someone describe a scenario where this (name of the binary not > clearly indicating it's related postgres) causes issues in practice? On > my system, there are ~1400 binaries in /usr/bin, and for the vast > majority of the

MSVC Build support with visual studio 2019

Hi Hackers, Here I attached a patch that supports building of PostgreSQL with VS 2019. VS 2019 is going to release on Apr 2nd 2019, it will be good if version 12 supports compiling. The attached for is for review, it may needs some updates once the final version is released. Commit d9dd406fe281d2

Re: MSVC Build support with visual studio 2019

On Thu, Mar 21, 2019 at 11:36:42AM +1100, Haribabu Kommi wrote: > I can provide a separate back branches patch later once this patch comes to > a stage of commit. Currently all the supported branches are possible to > compile with VS 2017. When it comes to support newer versions of MSVC, we have c

Re: PostgreSQL pollutes the file system

On Thu, Mar 21, 2019 at 08:41:32AM +0900, Tatsuo Ishii wrote: >> Can someone describe a scenario where this (name of the binary not >> clearly indicating it's related postgres) causes issues in practice? On >> my system, there are ~1400 binaries in /usr/bin, and for the vast >> majority of them it'

MacPorts support for "extra" tests

Hello hackers, Peter E added some nice tests for LDAP and Kerberos, but they assume you have Homebrew when testing on a Mac. Here's a patch to make them work with MacPorts too (a competing open source port/package distribution that happens to be the one that I use). The third "extra" test is ssl

  1   2   >