Hi,
Thank you for updating the patch.
On 2018/12/17 17:48, Pavel Stehule wrote:
> new update of this patch
Documentation portion of this patch still contains some typos that I
mentioned before here:
https://www.postgresql.org/message-id/1c83bb5c-47cd-d796-226c-e95795b05551%40lab.ntt.co.jp
+
Hi all,
For very large databases, the dbsize function `pg_database_size_name()`
etc. could be quite slow, since it needs to call `stat()` system call on
every file in the target database.
We proposed a new solution to accelerate these dbsize functions which check
the disk usage of
On Mon, Dec 17, 2018 at 10:13:42PM -0300, Alvaro Herrera wrote:
> I think we need to accept the new output. It is saying that previously
> we would not invoke the hook on SET TABLESPACE for a partitioned table,
> which makes sense, and now we do invoke it, which also makes sense.
Indeed, that
On Mon, Dec 17, 2018 at 11:01:59AM +0900, Michael Paquier wrote:
> On Mon, Dec 17, 2018 at 10:22:28AM +0900, Amit Langote wrote:
>> On 2018/12/15 8:00, Michael Paquier wrote:
>>> I tend to agree with your comment here. pg_tables lists partitioned
>>> tables, but pg_indexes is forgotting about
Hi,
On 2018/12/18 14:56, Kyotaro HORIGUCHI wrote:
> Hello.
>
> At Sun, 16 Dec 2018 17:47:16 -0300, Alvaro Herrera
> wrote in <20181216204716.jddzijk3fb2dpdk4@alvherre.pgsql>
>> On 2018-Dec-07, Michael Paquier wrote:
>>
>>> A macro makes sense to control that.
>>
>> I added Ashutosh's
On Mon, Dec 17, 2018 at 10:52 PM Andrey Lepikhov
wrote:
> I did many tests of your solution inside the 'quick vacuum' strategy [1]
> and the background worker called 'heap cleaner' [2]. I must admit that
> when I use your patch, there is no problem with dependencies.
Cool.
> This patch needs
On 08.12.2018 6:58, Peter Geoghegan wrote:
I have no idea what you mean here. I'm proposing a patch that stops
it being a game of chance, while preserving the existing
slightly-random behavior to the greatest extent possible. I think that
my patch would have stopped that problem altogether.
On Sun, Dec 16, 2018 at 05:47:16PM -0300, Alvaro Herrera wrote:
> I don't follow. When a relfilenode is passed by callers, they indicate
> that the storage has already been created. Contrariwise, when a
> relation kind that *does* have storage but is not yet created, they
> pass InvalidOid as
Hello.
At Sun, 16 Dec 2018 17:47:16 -0300, Alvaro Herrera
wrote in <20181216204716.jddzijk3fb2dpdk4@alvherre.pgsql>
> On 2018-Dec-07, Michael Paquier wrote:
>
> > A macro makes sense to control that.
>
> I added Ashutosh's RELKIND_HAS_STORAGE, but renamed it to
> RELKIND_CAN_HAVE_STORAGE,
On 30.11.2018 15:10, Dmitry Dolgov wrote:
Thank you. I played a bit with this patch, and can confirm visible WAL size
reduction (it's rather obvious, but still). Although, probably due to lack of
my knowledge here, I wonder how does it work when an index is build
concurrently?
Routine
On Wed, Dec 12, 2018 at 3:54 PM Haribabu Kommi wrote:
>
> On Thu, Nov 29, 2018 at 1:57 PM Amit Kapila wrote:
>> >
>>
>> Agreed. Hari, can you change the patch as per the requirements of option-4.
>
>
> Apologies for delay. Thanks to all your opinions.
>
> Attached is the updated patch as per
James Coleman writes:
> Is there anything I can do to solicit reviewers for the current CF?
There is no active CF, which is why nothing is happening. We'll
start looking at the 2019-01 items in January. Right now, people
are either on vacation or working on their own patches.
Is there anything I can do to solicit reviewers for the current CF?
The patch is quite small and should be fairly simple to review.
- James
From: Nagaura, Ryohei [mailto:nagaura.ryo...@jp.fujitsu.com]
> There is a demand for ECPG to support UNICODE host variables.
> This topic has also appeared in thread [1].
> I would like to discuss whether to support in postgres.
>
> Do you have any opinion?
* What's the benefit of supporting
Isaac Morland writes:
> On Mon, 17 Dec 2018 at 18:00, Tom Lane wrote:
>> tl;dr: we should model it after the behavior of IEEE float infinities,
>> except we'll want to throw errors where those produce NaNs.
> Would it be OK to return NULL for ∞ - ∞?
IMO, no. The only thing worse than
On 2018/12/18 10:57, Michael Paquier wrote:
> On Mon, Dec 17, 2018 at 07:49:42PM +0900, Michael Paquier wrote:
>> Okay, this suggestion sounds fine to me. Thanks!
>
> And committed with all your suggestions included. Thanks for the
> discussion.
Thank you!
Regards,
Amit
On Mon, Dec 17, 2018 at 07:49:42PM +0900, Michael Paquier wrote:
> Okay, this suggestion sounds fine to me. Thanks!
And committed with all your suggestions included. Thanks for the
discussion.
--
Michael
signature.asc
Description: PGP signature
On Mon, 17 Dec 2018 at 18:00, Tom Lane wrote:
> > so I was thinking that
> > postgres=# select 'infinity'::timestamp - 'infinity'::timestamp;
> > would be zero rather than an error, for least surprise.
>
> Wrong. This case needs to be undefined, because "infinity"
> isn't a specific value.
On 2018-Dec-18, Michael Paquier wrote:
> On Tue, Dec 18, 2018 at 09:36:17AM +1300, David Rowley wrote:
> > On Tue, 18 Dec 2018 at 08:21, Alvaro Herrera
> > wrote:
> >> Pushed with those changes. Thanks for the patch!
> >
> > Thanks for committing it and thanks for reviewing it, Michael.
>
>
On Tue, Dec 18, 2018 at 09:36:17AM +1300, David Rowley wrote:
> On Tue, 18 Dec 2018 at 08:21, Alvaro Herrera wrote:
>> Pushed with those changes. Thanks for the patch!
>
> Thanks for committing it and thanks for reviewing it, Michael.
Perhaps too early to speak, tests of sepgsql are broken
Hi,
On 2018-12-15 11:34:10 -0800, Andres Freund wrote:
> [1] We should optimize the computation using pg_add_s{32,64}_overflow,
> the generated code after that change is *substantially* better (as
> well as the original code much shorter, and correct). And consider,
> as mentioned
On Mon, Dec 17, 2018 at 02:24:08PM -0500, Tom Lane wrote:
> I eyeballed the patch, and it seems reasonable to me as well. The test
> case could perhaps be made more extensive (say, a multicolumn index
> with a mix of columns with and without stats targets) but I'm not sure
> that it's worth the
On Mon, Dec 17, 2018 at 06:52:51PM -0300, Alvaro Herrera wrote:
> On 2018-Dec-17, Robert Haas wrote:
> This patch missing the CF deadline would not be a happy way for me to
> begin the new year.
>
> I'm not sure what's the best way to move forward with this patch, but I
> encourage you to post
Hi,
On 2018-12-18 00:38:16 +0100, Tomas Vondra wrote:
> On 12/17/18 11:16 PM, Tom Lane wrote:
> > Tomas Vondra writes:
> >> Yeah, I've been thinking about that too. Currently it gets filtered out
> >> because it's in the CLIENT_CONN_STATEMENT group, but the code only
> >> includes
Hi,
On 2018-12-18 00:36:55 +0100, David Fetter wrote:
> On Mon, Dec 17, 2018 at 05:31:22PM -0500, Tom Lane wrote:
> > David Fetter writes:
> > > Please find attached a run of a tool that looks for duplicated
> > > tokens. I've removed some things that seem like false positives,
> > > basically
On Mon, Dec 17, 2018 at 05:31:22PM -0500, Tom Lane wrote:
> David Fetter writes:
> > Please find attached a run of a tool that looks for duplicated
> > tokens. I've removed some things that seem like false positives,
> > basically all from the stemmer part of the source, but there's
> > still a
On 12/17/18 11:16 PM, Tom Lane wrote:
> Tomas Vondra writes:
>> On 12/17/18 10:56 PM, legrand legrand wrote:
>>> what would you think about adding
>>> search_path
>>> to that list ?
>
>> Yeah, I've been thinking about that too. Currently it gets filtered out
>> because it's in the
On Mon, Dec 17, 2018 at 3:35 PM Alexander Korotkov
wrote:
> On Mon, Dec 17, 2018 at 3:40 AM Alexander Korotkov
> wrote:
> > On Mon, Dec 17, 2018 at 1:25 AM Andres Freund wrote:
> > > On 2018-12-17 01:03:52 +0300, Alexander Korotkov wrote:
> > > > Sorry for delay. Attached patch implements
Simon Riggs writes:
> I would like to represent 'infinity' as interval->months = INT_MAX
Per the discussion upthread, what we need when creating an
infinite value is to set
month = INT32_MAX, day = INT32_MAX, time = INT64_MAX (for +Infinity)
month = INT32_MIN, day = INT32_MIN, time = INT64_MIN
On Mon, Dec 17, 2018 at 8:32 AM Corey Huinker wrote:
> All suggestions are appreciated.
As I recall, the main issue is how to handle concurrency. The
existing RI triggers do some very special handling of the multi-xact
ID to manage concurrent modifications. Has anyone looked at the
issues
On Mon, Dec 17, 2018 at 11:27 AM Alvaro Herrera
wrote:
> On 2018-Dec-17, Pavel Stehule wrote:
>
>> ROW trigger call RI check too often, and statement trigger too less. I
>> think so ideal design can be call RI check every 10K rows. I think so can
>> be unfriendly if somebody does very long import
Alvaro Herrera writes:
> On the other hand, I'm not clear on why do we need four copies of
> number_of_ones.
Yeah, it might be time to move something like that into a common
location. Not sure where the threshold of pain is, though.
regards, tom lane
On Mon, 17 Dec 2018 at 03:48, Tom Lane wrote:
> The positive argument for adding infinity to interval is that
> we define operations such as timestamp minus timestamp as
> yielding interval. That's why this has to fail right now:
>
> regression=# select timestamp 'infinity' - timestamp 'now';
Hi Alexey,
Thanks for the thorough and extremely valuable review!
On 12/17/18 5:23 PM, Alexey Kondratov wrote:
> Hi Tomas,
>
>> This new version is mostly just a rebase to current master (or almost,
>> because 2pc decoding only applies to 29180e5d78 due to minor bitrot),
>> but it also
Tomas Vondra writes:
> On 12/17/18 10:56 PM, legrand legrand wrote:
>> what would you think about adding
>> search_path
>> to that list ?
> Yeah, I've been thinking about that too. Currently it gets filtered out
> because it's in the CLIENT_CONN_STATEMENT group, but the code only
> includes
Hi,
On 12/17/18 10:56 PM, legrand legrand wrote:
> what would you think about adding
> search_path
> to that list ?
>
Yeah, I've been thinking about that too. Currently it gets filtered out
because it's in the CLIENT_CONN_STATEMENT group, but the code only
includes QUERY_TUNING_*.
But we
what would you think about adding
search_path
to that list ?
Regards
PAscal
--
Sent from: http://www.postgresql-archive.org/PostgreSQL-hackers-f1928748.html
On 2018-Dec-17, Robert Haas wrote:
> I have done a bit more work on this, but need to spend some more time
> on it before I have something that is worth posting. Not sure whether
> I'll get to that before the New Year at this point.
This patch missing the CF deadline would not be a happy way
On Tue, 18 Dec 2018 at 08:21, Alvaro Herrera wrote:
> Pushed with those changes. Thanks for the patch!
Thanks for committing it and thanks for reviewing it, Michael.
--
David Rowley http://www.2ndQuadrant.com/
PostgreSQL Development, 24x7 Support, Training & Services
On Sun, Dec 16, 2018 at 4:41 PM Alexander Korotkov
wrote:
> I thought about that, but decided it's better to mimic B-tree and hash
> behavior rather than invent new logic in a minor release. But given
> that new WAL record in minor release in substantial problem, that
> argument doesn't matter.
Rebased over today's conflicting commits.
--
Álvaro Herrerahttps://www.2ndQuadrant.com/
PostgreSQL Development, 24x7 Support, Remote DBA, Training & Services
diff --git a/src/backend/catalog/heap.c b/src/backend/catalog/heap.c
index 4d5b82aaa9..b128959cb7 100644
---
amul sul writes:
>> On Mon, Dec 17, 2018 at 11:54 AM Michael Paquier
>>> So this settles the argument that we had better not do anything before
>>> v11. Switching the dump code to use column numbers has not proved to be
>>> complicated as only the query and some comments had to be tweaked.
>>>
On 2018-Dec-18, David Rowley wrote:
> 1. Shouldn't you be using the RangeVarGetRelid() macro instead of
> calling RangeVarGetRelidExtended()?
This should have been obvious but I didn't notice.
> 2. In MergeAttributes(), the parentOids list still exists and is
> populated. This is now only used
po 17. 12. 2018 v 19:19 odesílatel Adam Brusselback <
adambrusselb...@gmail.com> napsal:
> It's something I know I am interested in. For me, I don't really care if
> my statement doesn't cancel until the very end if there is a RI violation.
> The benefit of not having deletes be slow on tables
It's something I know I am interested in. For me, I don't really care if my
statement doesn't cancel until the very end if there is a RI violation. The
benefit of not having deletes be slow on tables which have others
referencing it with a fkey which don't have their own index is huge IMO. I
have
Our deployment script failed to notice dozens of commands failed in a
transaction block and I only noticed due to keeping full logs and monitoring
for error_severity>'LOG'. I would have thought that exit status would be
nonzero had an error occured in an earlier script.
The docs since PG9.6 say:
po 17. 12. 2018 v 18:27 odesílatel Alvaro Herrera
napsal:
> On 2018-Dec-17, Pavel Stehule wrote:
>
> > ROW trigger call RI check too often, and statement trigger too less. I
> > think so ideal design can be call RI check every 10K rows. I think so can
> > be unfriendly if somebody does very long
On 2018-Dec-17, Pavel Stehule wrote:
> ROW trigger call RI check too often, and statement trigger too less. I
> think so ideal design can be call RI check every 10K rows. I think so can
> be unfriendly if somebody does very long import and it fails on the end. I
> don't think so there should not
Hi,
On 12/12/2018 21:41, Andres Freund wrote:
>
> I don't like the approach of managing the catalog horizon via those
> periodically logged catalog xmin announcements. I think we instead
> should build ontop of the records we already have and use to compute
> snapshot conflicts. As of HEAD we
On 2018-Dec-17, Tom Lane wrote:
> But it looks like
> we could drop the sys_siglist support for an undetectably small penalty:
> even if, somewhere, there's a platform that has sys_siglist[] but not
> strsignal(), it'd just mean that you get only a signal number and have
> to look up its meaning.
At 2018-12-17 11:52:03 -0500, t...@sss.pgh.pa.us wrote:
>
> While a dozen lines in pgstrsignal.c certainly are not worth worrying
> over, getting rid of the configure test for sys_siglist[] would save
> some cycles on every build. So I'm tempted to drop it. Thoughts?
Removing it makes sense to
Alvaro Herrera writes:
> On 2018-Dec-16, Tom Lane wrote:
>> I propose to replace all these places with code like
>>
>> snprintf(str, sizeof(str),
>> _("child process was terminated by signal %d: %s"),
>> WTERMSIG(exitstatus), pg_strsignal(WTERMSIG(exitstatus)));
po 17. 12. 2018 v 15:32 odesílatel Corey Huinker
napsal:
> Back when Pg added statement-level triggers, I was interested in the
> potential promise of moving referential integrity checks to statement-level
> triggers.
>
> The initial conversation, along with Kevin Grittner's POC script (in SQL)
Tom Lane wrote:
> Antonin Houska writes:
> > [ agg_pushdown_v8.tgz ]
>
> I spent a few hours looking at this today.
Thanks!
> It seems to me that at no point has there been a clear explanation of what
> the patch is trying to accomplish, so let me see whether I've got it
> straight or not.
> On Sat, Dec 15, 2018 at 8:37 PM Andres Freund wrote:
>
> We need to dump the table access method at dump time, otherwise we loose
> that information.
Oh, right. So, something like in the attached patch?
> > As a side note, in a table description I haven't found any mention of which
> > access
On Mon, Dec 17, 2018 at 11:49 PM Alvaro Herrera
wrote:
> On 2018-Dec-14, Amit Langote wrote:
>
> > I updated the patch. Regarding whether we should mention "(never
> > executed)", it wouldn't hurt to mention it imho, exactly because it's
> > shown in the place of showing loops=0. How about the
In digging around the codebase (see thread: Referential Integrity Checks
with Statement-level Triggers), I noticed that unique constraints are
similarly enforced with a per-row trigger.
The situation with unique indexes is fairly similar to the situation with
RI checks: there is some overhead to
On 2018-Dec-14, Amit Langote wrote:
> I updated the patch. Regarding whether we should mention "(never
> executed)", it wouldn't hurt to mention it imho, exactly because it's
> shown in the place of showing loops=0. How about the attached?
Pushed, thanks.
--
Álvaro Herrera
Thanks a lot Tom, as always :)
We generally do not have so many duplicates in production, so maybe this is
an edge case but I am happy with the explanation and the code reference for
the analysis.
I’ll also play with default statistic target to see what changes by
increasing the value.
On Sun,
Back when Pg added statement-level triggers, I was interested in the
potential promise of moving referential integrity checks to statement-level
triggers.
The initial conversation, along with Kevin Grittner's POC script (in SQL)
that showed a potential for a 98% reduction in time spent doing RI
On Mon, 17 Dec 2018 at 11:07, Alvaro Herrera wrote:
> First, I changed the Assert() to use the macro for relations with
> storage that I just posted in the other thread that Michael mentioned.
>
> I then noticed that we're doing a heap_openrv() in the parent relation
> and closing it before
On Sun, Dec 16, 2018 at 6:43 AM Michael Paquier wrote:
> On Sat, Dec 15, 2018 at 01:04:00PM +0300, Sergei Kornilov wrote:
> > Seems we erroneously moved this thread to next CF:
> > https://commitfest.postgresql.org/21/1842/
> > Can you close this entry?
>
> Robert has committed a patch to
On Mon, 17 Dec 2018 at 22:10, Amit Kapila wrote:
> Pushed, one of these goes back till 10.
Thanks.
--
David Rowley http://www.2ndQuadrant.com/
PostgreSQL Development, 24x7 Support, Training & Services
(2018/12/17 22:09), Etsuro Fujita wrote:
Here is a set of WIP patches for pushing down ORDER BY LIMIT to the remote:
* 0001-postgres-fdw-upperrel-ordered-WIP.patch:
Correction:
0001-postgres_fdw-Perform-UPPERREL_ORDERED-step-remotely-WIP.patch
* 0002-postgres-fdw-upperrel-final-WIP.patch:
(2018/10/09 14:48), Etsuro Fujita wrote:
(2018/10/05 19:15), Etsuro Fujita wrote:
(2018/08/02 23:41), Tom Lane wrote:
Andrew Gierth writes:
[ postgres_fdw is not smart about exploiting fast-start plans ]
Yeah, that's basically not accounted for at all in the current design.
One
Hi,
On Thu, 6 Dec 2018 at 00:55, Petr Jelinek wrote:
> > Does excluding WAL senders from the max_connections limit and including
> > max_wal_senders in MaxBackends also imply that we need to add
> > max_wal_senders to the list at xlog.c: CheckRequiredParameterValues,
> > requiring its value
On Mon, Dec 17, 2018 at 3:40 AM Alexander Korotkov
wrote:
> On Mon, Dec 17, 2018 at 1:25 AM Andres Freund wrote:
> > On 2018-12-17 01:03:52 +0300, Alexander Korotkov wrote:
> > > Sorry for delay. Attached patch implements conflict handling for gist
> > > microvacuum like btree and hash. I'm
Hello. One more weight comes here.
At Sat, 15 Dec 2018 08:03:46 +0530, Amit Kapila wrote
in
> On Sat, Dec 15, 2018 at 12:14 AM Robert Haas wrote:
> >
> > On Wed, Nov 28, 2018 at 1:43 PM Alvaro Herrera
> > wrote:
> > > Right, I think option 4 is a clear improvement over option 1. I can get
On Mon, Dec 17, 2018 at 06:35:03PM +0900, Amit Langote wrote:
> As far as the information content of this comment is concerned, I think
> it'd be more useful to word this comment such that it is applicable to
> different functions than to word it such that it is applicable to
> different queries.
On Fri, Nov 30, 2018 at 7:16 PM Dmitry Dolgov <9erthali...@gmail.com> wrote:
>
> Unfortunately, patch needs to be rebased, could you please post an updated
> version?
>
Thank you for informing, Here is an updated patch against current master
Regards
Surafel
diff --git
Nagaura-san
I understand that the previous discussion pointed that the feature had better
be implemented more simply or step-by-step and description about implementation
is needed more.
I also think it prevented the discussion to reach to the detail of feature.
What is your opinion about it?
On 2018/12/17 18:10, Michael Paquier wrote:
> On Mon, Dec 17, 2018 at 05:56:08PM +0900, Amit Langote wrote:
>> You're saying that we should use plural "functions" because there of 2
>> *instances* of calling the function pg_partition_tree in the queries that
>> follow the comment, but I think that
On Mon, Dec 17, 2018 at 12:20 PM amul sul wrote:
> On Mon, Dec 17, 2018 at 11:54 AM Michael Paquier
> wrote:
> >
> > On Mon, Dec 17, 2018 at 12:24:15AM -0500, Tom Lane wrote:
> > > If we were to rename the "foo.expr" column at this point,
> > > and then dump and reload, the expression column in
Meskes-san
I noticed that I was confused.
My topic was about adding bytea as new host variable type.
The topic *didn't* include that receiving binary format data
into SQLDATA descriptor like the following.
sqlda_t *sqlda;
exec sql create table if not exists test (c1 bytea);
exec sql
On Mon, Dec 17, 2018 at 05:56:08PM +0900, Amit Langote wrote:
> You're saying that we should use plural "functions" because there of 2
> *instances* of calling the function pg_partition_tree in the queries that
> follow the comment, but I think that would be misleading. I think the
> plural would
On Mon, Dec 17, 2018 at 1:00 PM Amit Kapila wrote:
>
> On Mon, Dec 17, 2018 at 1:53 AM David Rowley
> wrote:
> >
> > While looking over some recent commits, I noticed there are some code
> > lines with a double trailing semicolon instead of a single one.
>
Pushed, one of these goes back till
On 2018/12/17 17:25, Michael Paquier wrote:
> On Mon, Dec 17, 2018 at 04:41:01PM +0900, Amit Langote wrote:
>> Okay, let's use "Functions" then, although I wonder if you shouldn't tweak
>> it later when you commit the pg_partition_root patch?
>
> There are already two calls to pg_partition_tree
Hi
pá 30. 11. 2018 v 20:06 odesílatel Pavel Stehule
napsal:
>
>
> čt 29. 11. 2018 v 7:58 odesílatel Michael Paquier
> napsal:
>
>> On Thu, Nov 22, 2018 at 03:47:11PM +0100, Pavel Stehule wrote:
>> > I have not feel well when I see in one report numbers 40 and 16, I see
>> much
>> > more
Hi all.
There is a demand for ECPG to support UNICODE host variables.
This topic has also appeared in thread [1].
I would like to discuss whether to support in postgres.
Do you have any opinion?
The specifications and usage described below are the same as in [1].
Requirements
1.
On Mon, Dec 17, 2018 at 1:57 PM Michael Paquier wrote:
> On Mon, Dec 17, 2018 at 01:19:00PM +0530, amul sul wrote:
> > Laptop215:PG edb$ git --version
> > git version 2.14.1
>
> Using 2.20, git apply works fine for me but... If patch -p1 works, why
> not just using it then? It is always
On Mon, Dec 17, 2018 at 01:19:00PM +0530, amul sul wrote:
> Laptop215:PG edb$ git --version
> git version 2.14.1
Using 2.20, git apply works fine for me but... If patch -p1 works, why
not just using it then? It is always possible to check the patch for
whitespaces or such with "git diff
On Mon, Dec 17, 2018 at 04:41:01PM +0900, Amit Langote wrote:
> Okay, let's use "Functions" then, although I wonder if you shouldn't tweak
> it later when you commit the pg_partition_root patch?
There are already two calls to pg_partition_tree for each one of the two
relkinds tested.
--
Michael
82 matches
Mail list logo
