(2019/03/11 14:14), Tom Lane wrote:
Etsuro Fujita writes:
(2019/03/11 13:06), Tom Lane wrote:
Is that the only possible outcome? Per Robert's summary quoted above,
it seems like it might be possible for the code to decide that the final
scan/join target to be parallel safe when it is not,
Etsuro Fujita writes:
> (2019/03/11 13:06), Tom Lane wrote:
>> Is that the only possible outcome? Per Robert's summary quoted above,
>> it seems like it might be possible for the code to decide that the final
>> scan/join target to be parallel safe when it is not, leading to outright
>> wrong
On Mon, Mar 11, 2019 at 8:29 AM Ashutosh Bapat
wrote:
> On Thu, Mar 7, 2019 at 8:20 PM amul sul wrote:
>
>>
>>
>> On Thu, Mar 7, 2019 at 1:02 PM amul sul wrote:
>>
>>> Thanks Rajkumar,
>>>
>>> I am looking into this.
>>>
>>>
>> The crash happens when none of the if-else branch of
>>
(2019/03/11 13:06), Tom Lane wrote:
Etsuro Fujita writes:
The parallel safety of the final scan/join target is determined from the
grouping target, not that target, which [ is wrong ]
This would only affect plan quality a little bit, so I don't think we
need a regression test for this,
On Wed, Feb 27, 2019 at 07:59:31AM +0100, Fabien COELHO wrote:
> Hallo Michael,
Okay, let's move on with these patches!
> The renaming implies quite a few changes (eg in the documentation,
> makefiles, tests) which warrants a review, so it should be a patch. Also,
> ISTM that the renaming only
On 2019/03/11 13:22, Justin Pryzby wrote:
> On Mon, Mar 11, 2019 at 01:06:08PM +0900, Amit Langote wrote:
>> On 2019/03/11 11:13, David Rowley wrote:
>>> On Mon, 11 Mar 2019 at 15:00, David Rowley
>>> wrote:
On Mon, 11 Mar 2019 at 14:33, Amit Langote
wrote:
> PG 11 moved the
On Mon, Mar 11, 2019 at 01:06:08PM +0900, Amit Langote wrote:
> On 2019/03/11 11:13, David Rowley wrote:
> > On Mon, 11 Mar 2019 at 15:00, David Rowley
> > wrote:
> >> On Mon, 11 Mar 2019 at 14:33, Amit Langote
> >> wrote:
> >>> PG 11 moved the needle a bit for SELECT queries:
> >>>
> >>>
On 2019/03/11 11:13, David Rowley wrote:
> On Mon, 11 Mar 2019 at 15:00, David Rowley
> wrote:
>>
>> On Mon, 11 Mar 2019 at 14:33, Amit Langote
>> wrote:
>>> PG 11 moved the needle a bit for SELECT queries:
>>>
>>> Excluding unnecessary partitions is slow for UPDATE and DELETE queries,
>>
>>
Etsuro Fujita writes:
>>> The parallel safety of the final scan/join target is determined from the
>>> grouping target, not that target, which [ is wrong ]
> This would only affect plan quality a little bit, so I don't think we
> need a regression test for this, either, but the fix might
(2019/03/09 5:36), Tom Lane wrote:
Etsuro Fujita writes:
(2019/02/28 0:52), Robert Haas wrote:
On Tue, Feb 26, 2019 at 7:26 AM Etsuro Fujita
wrote:
The parallel safety of the final scan/join target is determined from the
grouping target, not that target, which [ is wrong ]
Your patch
On Mon, Mar 11, 2019 at 8:45 AM Tom Lane wrote:
>
> Michael Paquier writes:
> > On Sun, Mar 10, 2019 at 07:18:20PM +, Tom Lane wrote:
> I think what's going on here is what's mentioned in the comments in
> float8in_internal:
>
> * C99 requires that strtod() accept NaN, [+-]Infinity,
On Mon, 11 Mar 2019 at 00:13, Sergei Kornilov wrote:
>
> > Providing I'm imagining it correctly, I do think the patch is slightly
> > cleaner with that change.
>
> Ok, sounds reasonable. I changed patch this way.
Looks good to me. Good idea to keep the controversial setting of
Michael Paquier writes:
> On Sun, Mar 10, 2019 at 07:18:20PM +, Tom Lane wrote:
>> Include GUC's unit, if it has one, in out-of-range error messages.
> It does not seem to have cooled down all animals yet, whelk is
> still complaining:
>
On 3/10/19 11:27 PM, David Rowley wrote:
> On Mon, 11 Mar 2019 at 06:36, Tomas Vondra
> wrote:
>>
>> On 3/9/19 7:33 PM, Dean Rasheed wrote:
>>> I wonder if it's possible to write smaller, more targeted tests.
>>> Currently "stats_ext" is by far the slowest test in its group, and I'm
>>> not
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.
I also liked the design in the https://postgr.es/m/559fa0ba.3080...@iki.fi
last paragraph, and I suspect it would have been no harder to
Hi, Fabien-san.
> From: Fabien COELHO
> As I understand the "client-side timeout" use-case, as distinct from
> network-issues-related timeouts proposed in the other patches, the point is
> more
> or less to deal with an overloaded server.
The main purpose of this parameter is to avoid client's
On Sat, Mar 9, 2019 at 2:18 PM Andres Freund wrote:
> Hi,
>
> On 2019-03-09 11:03:21 +1100, Haribabu Kommi wrote:
> > Here I attached the rebased patches that I shared earlier. I am adding
> the
> > comments to explain the API's in the code, will share those patches
> later.
>
> I've started to
On Mon, 11 Mar 2019 at 15:00, David Rowley wrote:
>
> On Mon, 11 Mar 2019 at 14:33, Amit Langote
> wrote:
> > PG 11 moved the needle a bit for SELECT queries:
> >
> > Excluding unnecessary partitions is slow for UPDATE and DELETE queries,
>
> With those words I expect the user might be surprised
On 2019/03/11 11:00, David Rowley wrote:
> On Mon, 11 Mar 2019 at 14:33, Amit Langote
> wrote:
>> PG 11 moved the needle a bit for SELECT queries:
>>
>> Excluding unnecessary partitions is slow for UPDATE and DELETE queries,
>
> With those words I expect the user might be surprised that it's
Dear Rushabh, Michael,
I attached a simple bug-fixing patch.
Could you review it?
An added logic is:
1. Send a close statement to a backend process regardless of the existence
of a cursor.
2. If ecpg_do function returns false, raise “cursor is invalid” error.
3. Remove cursor
On Mon, 11 Mar 2019 at 14:33, Amit Langote
wrote:
> PG 11 moved the needle a bit for SELECT queries:
>
> Excluding unnecessary partitions is slow for UPDATE and DELETE queries,
With those words I expect the user might be surprised that it's still
slow after doing SET enable_partition_pruning =
On 2019/03/11 0:25, Justin Pryzby wrote:
> On Sun, Mar 10, 2019 at 10:53:02PM +1300, David Rowley wrote:
>> On Fri, 11 May 2018 at 17:37, Amit Langote
>> wrote:
>>> 5. The last sentence in caveats, that is,
>>>
>>> "Partitioning using these techniques will work well with up to perhaps a
>>>
On Mon, Feb 25, 2019 at 4:50 PM Masahiko Sawada wrote:
>
> On Wed, Feb 20, 2019 at 1:00 PM Masahiko Sawada wrote:
> >
> > BTW, XLogRecPtrIsInvalid(copy_restart_lsn) || copy_restart_lsn <
> > src_restart_lsn is redundant, the former should be removed.
> >
>
> So attached the updated version
On 2019-03-10 13:29:06 -0300, Alvaro Herrera wrote:
> Hello
>
> On 2019-Mar-08, Andres Freund wrote:
>
> > > diff --git a/src/bin/pg_dump/pg_dump.c b/src/bin/pg_dump/pg_dump.c
> > > index e962ae7e913..1de8da59361 100644
> > > --- a/src/bin/pg_dump/pg_dump.c
> > > +++ b/src/bin/pg_dump/pg_dump.c
Amit-san,
On Fri, Mar 8, 2019 at 9:18 AM, Amit Langote wrote:
> On 2019/03/08 16:16, Imai, Yoshikazu wrote:
> > So I modified the code and did test to confirm memory increasement don't
> happen. The test and results are below.
> >
> > [test]
> > * Create partitioned table with 1536 partitions.
>
DECLARE cur CURSOR with hold FOR SELECT * FROM t;
the "with hold" is designed for this purpose. sorry for this
interruption.
On Sun, Mar 10, 2019 at 4:14 PM Andy Fan wrote:
> for example:
> begin;
> declare cur cursor for select * from t;
> insert into t2 values(...);
> fetch next cur;
>
On Fri, Mar 08, 2019 at 10:27:52AM +0900, Michael Paquier wrote:
> After sleeping on it, let's live with just switching to nleft in the
> message, without openLogOff as that's the second time folks complain
> about the previous code. So I just propose the attached. Robert,
> others, any
Hi, hackers.
Attached patches add missing distance operator <->(box, point).
We already have reverse operator <->(point, box), but it can't be used for kNN
search in GiST and SP-GiST. GiST and SP-GiST now support kNN searches over more
complex polygons and circles, but do not support more
David Rowley writes:
> On Wed, 27 Feb 2019 at 01:57, Simon Riggs wrote:
>> I've put it as 256 args now.
>
> I had a look at this and I see you've added some docs to mention the
> number of parameters that are allowed; good.
>
> + pgbench supports up to 256 variables in one
> + statement.
>
Andy Fan writes:
> for example:
> begin;
> declare cur cursor for select * from t;
> insert into t2 values(...);
> fetch next cur;
> commit;
>
> // after this, I can't fetch cur any more.
>
> My question are:
> 1. Is this must in principle? or it is easy to implement as this in PG?
It is
On Sat, Mar 09, 2019 at 09:09:24AM +0900, Michael Paquier wrote:
> When working on the first version of pg_rewind for VMware with Heikki,
> tablespace support has been added only after, so what you propose is
> sensible I think.
>
> +# Run the test in both modes.
> +run_test('local');
> Small
On Sun, Mar 10, 2019 at 06:56:57PM +0530, Ramanarayana wrote:
> Will it be helpful if the comments section of ExecuteStmt in gram.y is
> updated to include the IF NOT EXISTS clause.Something like this
>
> CREATE TABLE [IF NOT EXISTS] AS EXECUTE [(params, ...)]
Not sure it helps much. The
On Mon, 11 Mar 2019 at 06:36, Tomas Vondra wrote:
>
> On 3/9/19 7:33 PM, Dean Rasheed wrote:
> > I wonder if it's possible to write smaller, more targeted tests.
> > Currently "stats_ext" is by far the slowest test in its group, and I'm
> > not sure that some of those tests add much. It ought to
> On Mon, Mar 4, 2019 at 7:15 PM Andres Freund wrote:
>
> The pluggable storage patchset contains exactly that... I've attached
> the precursor patch (CREATE ACCESS METHOD ... TYPE TABLE), and the patch
> for pg_dump support. They need a bit more cleanup, but it might be
> useful information for
Julien Rouhaud writes:
> On Sat, Mar 9, 2019 at 10:04 PM Tom Lane wrote:
>> 2. It's always bugged me that we don't allow fractional unit
>> specifications, say "0.1GB", even for GUCs that are integers underneath.
>> That would be a simple additional change on top of this, but I didn't
>> do it
On Sun, Mar 10, 2019 at 12:53 PM Heikki Linnakangas wrote:
> Ah, yeah. Not sure. I wrote it as "searching_for_pivot_tuple" first, but
> changed to "searching_for_leaf_page" at the last minute. My thinking was
> that in the page-deletion case, you're trying to re-locate a particular
> leaf page.
On 2019-Feb-07, Tomas Vondra wrote:
> Attached is a WIP patch removing the optimization from DropRelationFiles
> and adding it to smgrDoPendingDeletes. This resolves the issue, at least
> in the cases I've been able to reproduce. But maybe we should deal with
> this issue earlier by ensuring the
On 10/03/2019 20:53, Peter Geoghegan wrote:
On Sun, Mar 10, 2019 at 7:09 AM Heikki Linnakangas wrote:
If we don't flip the meaning of the flag, then maybe calling it
something like "searching_for_leaf_page" would make sense:
/*
* When set, we're searching for the leaf page with the given
On Wed, Mar 06, 2019 at 10:06:27PM +0800, Paul Guo wrote:
> Hello, Postgres hackers,
>
> The copy code has used batch insert with function heap_multi_insert() to
> speed up. It seems that Create Table As or Materialized View could leverage
> that code also to boost the performance also. Attached
Thank you.
Here is my latest attempt, with actual syntax error handling.
Also, the syntax is updated to what Tom Lane suggested in other
thread (with another variant of the same thing, from Julien Demoor)
NOTIFY [ ( option [, ...] ) ] channel [ , payload ]
Still no hash table fallback is
Thank you. Updated patch attached.
On Sat, Mar 9, 2019 at 2:53 AM Thomas Munro wrote:
>
> On Wed, Mar 6, 2019 at 1:39 PM Filip Rembiałkowski
> wrote:
> > Here is Pavel's patch rebased to master branch, added the dropdb
> > --force option, a test case & documentation.
>
> Hello,
>
>
On Sun, Mar 10, 2019 at 7:09 AM Heikki Linnakangas wrote:
> "descendrighttrunc" doesn't make much sense to me, either. I don't
> understand it. Maybe a comment would make it clear, though.
It's not an easily grasped concept. I don't think that any name will
easily convey the idea to the reader,
On 2/13/19 1:12 PM, Andres Freund wrote:
> Hi,
>
> On 2019-02-13 12:59:19 -0500, Tom Lane wrote:
>> Andres Freund writes:
>>> On 2019-02-13 12:37:35 -0500, Tom Lane wrote:
Bleah. But in any case, the rename should not create a situation
in which we need to fsync the file data again.
On Mon, Mar 04, 2019 at 05:46:07PM -0300, Alvaro Herrera wrote:
> Hi Rahila,
>
> Thanks for looking.
>
> On 2019-Mar-04, Rahila wrote:
>
> > 1. Thank you for incorporating review comments.
> > Can you please rebase the latest 0001-Report-progress-of-
> > CREATE-INDEX-operations.patch on master?
Hi Dean,
Thanks for the review. I'll post a patch fixing most of the stuff soon,
but a few comments/questions regarding some of the issues:
On 3/9/19 7:33 PM, Dean Rasheed wrote:
> 5). It's not obvious what some of the new test cases in the
> "stats_ext" tests are intended to show. For example,
On Sat, Mar 9, 2019 at 1:14 AM Tom Lane wrote:
> I took a quick look at this. I went ahead and pushed the parts that
> were just code cleanup in reformat_dat_file.pl, since that seemed
> pretty uncontroversial. As far as the rest of it goes:
Okay, thanks.
> * I'm really not terribly happy
Hi!
> 10 марта 2019 г., в 13:39, Alexander Korotkov
> написал(а):
>
> Pushed with some more small changes in docs.
That's great, thank you!
Best regards, Andrey Borodin.
> 5 марта 2019 г., в 18:21, Heikki Linnakangas написал(а):
>
> On 05/03/2019 02:26, Andrey Borodin wrote:
>>
>> That's cool! I'll work on 2nd step of these patchset to make
>> blockset data structure prettier and less hacky.
>
> Committed the first patch. Thanks for the patch!
That's cool!
so 9. 3. 2019 v 22:17 odesílatel Pavel Stehule
napsal:
>
>
> čt 7. 3. 2019 v 18:45 odesílatel Andrew Dunstan <
> andrew.duns...@2ndquadrant.com> napsal:
>
>>
>> On 3/7/19 12:41 PM, Pavel Stehule wrote:
>> >
>> >
>> > čt 7. 3. 2019 v 18:35 odesílatel Andrew Dunstan
>> > > >
Hello
On 2019-Mar-08, Andres Freund wrote:
> > diff --git a/src/bin/pg_dump/pg_dump.c b/src/bin/pg_dump/pg_dump.c
> > index e962ae7e913..1de8da59361 100644
> > --- a/src/bin/pg_dump/pg_dump.c
> > +++ b/src/bin/pg_dump/pg_dump.c
> > @@ -4359,9 +4359,9 @@
On Sun, 10 Mar 2019 at 13:09, Dean Rasheed wrote:
> Here are some more comments:
>
One more thing --- the comment for statext_clauselist_selectivity() says:
* So (simple_selectivity - base_selectivity) may be seen as a correction for
* the part not covered by the MCV list.
That's not quite
On Sun, Mar 10, 2019 at 4:47 PM Tom Lane wrote:
>
> Julien Rouhaud writes:
> > On Sat, Mar 9, 2019 at 10:04 PM Tom Lane wrote:
> >> I tried this, and it seems to work pretty well. The first of the two
> >> attached patches just teaches guc.c to support units for float values,
> >> incidentally
Julien Rouhaud writes:
> On Sat, Mar 9, 2019 at 10:04 PM Tom Lane wrote:
>> I tried this, and it seems to work pretty well. The first of the two
>> attached patches just teaches guc.c to support units for float values,
>> incidentally allowing "us" as an input unit for time-based GUCs.
> Why
On Sun, Mar 10, 2019 at 10:53:02PM +1300, David Rowley wrote:
> On Fri, 11 May 2018 at 17:37, Amit Langote
> wrote:
> > 5. The last sentence in caveats, that is,
> >
> > "Partitioning using these techniques will work well with up to perhaps a
> > hundred partitions; don't try to use many
On Fri, Mar 8, 2019 at 7:43 PM Amit Kapila wrote:
> Few minor comments:
> 1.
> warning C4715: 'new_cluster_needs_fsm': not all control paths return a value
>
> Getting this new warning in the patch.
Hmm, I don't get that in a couple versions of gcc. Your compiler must
not know that pg_fatal()
On 08/03/2019 23:21, Peter Geoghegan wrote:
On Fri, Mar 8, 2019 at 10:48 AM Peter Geoghegan wrote:
All of that said, maybe it would be clearer if page deletion was not
the special case that has to opt in to minusinfkey semantics. Perhaps
it would make more sense for everyone else to opt out of
Sorry for the late reply.
To Michael. Thank you. I know this commitfest is ongoing and I'm not
targeting for this.
On Thu, Mar 7, 2019 at 4:54 PM Heikki Linnakangas wrote:
> On 06/03/2019 22:06, Paul Guo wrote:
> > The patch also modifies heap_multi_insert() a bit to do a bit further
> >
Hi,
Will it be helpful if the comments section of ExecuteStmt in gram.y is
updated to include the IF NOT EXISTS clause.Something like this
CREATE TABLE [IF NOT EXISTS] AS EXECUTE [(params, ...)]
Regards,
Ram.
On Sat, Mar 9, 2019 at 11:14 PM Tom Lane wrote:
>
> BTW ... I noticed while fooling with this that GUC's out-of-range
> messages can be confusing:
>
> regression=# set vacuum_cost_delay = '1s';
> ERROR: 1000 is outside the valid range for parameter "vacuum_cost_delay" (0
> .. 100)
>
> One's
On Sat, 9 Mar 2019 at 18:33, Dean Rasheed wrote:
>
> On Thu, 28 Feb 2019 at 19:56, Tomas Vondra
> wrote:
> > Attached is an updated version of this patch series.
>
> Here are some random review comments. I'll add more later, but I'm out
> of energy for today.
>
Here are some more comments:
On Sat, Mar 9, 2019 at 10:04 PM Tom Lane wrote:
>
> I tried this, and it seems to work pretty well. The first of the two
> attached patches just teaches guc.c to support units for float values,
> incidentally allowing "us" as an input unit for time-based GUCs.
Why not allowing third party
On Sat, Mar 9, 2019 at 7:58 PM Julien Rouhaud wrote:
>
> On Sat, Mar 9, 2019 at 7:50 PM Magnus Hagander wrote:
> >
> > On Sat, Mar 9, 2019 at 10:41 AM Julien Rouhaud wrote:
> >>
> >> Sorry, I have again new comments after a little bit more thinking.
> >> I'm wondering if we can do something
Attached is a rebase.
--
Fabien.diff --git a/src/bin/pgbench/pgbench.c b/src/bin/pgbench/pgbench.c
index 5df54a8e57..1db6b75823 100644
--- a/src/bin/pgbench/pgbench.c
+++ b/src/bin/pgbench/pgbench.c
@@ -6032,6 +6032,96 @@ main(int argc, char **argv)
return exit_code;
}
+/* display the
Hi
> Providing I'm imagining it correctly, I do think the patch is slightly
> cleaner with that change.
Ok, sounds reasonable. I changed patch this way.
regards, Sergeidiff --git a/doc/src/sgml/ref/alter_table.sgml b/doc/src/sgml/ref/alter_table.sgml
index 890b23afd6..926b3361ea 100644
---
On Sun, 10 Mar 2019 at 21:34, David Rowley wrote:
> I started looking at this again and I came up with the attached
> eclass_indexes_v2.patch.
The CF bot didn't like v2. It warned about an uninitialized variable.
My compiler didn't.
Here's v3, hopefully with that fixed.
--
David Rowley
On Fri, 11 May 2018 at 17:37, Amit Langote
wrote:
> 5. The last sentence in caveats, that is,
>
> "Partitioning using these techniques will work well with up to perhaps a
> hundred partitions; don't try to use many thousands of partitions."
>
> should perhaps be reworded as:
>
> "So the legacy
On Fri, Mar 8, 2019 at 11:58 AM Alexander Korotkov
wrote:
> I made some adjustments for this patch:
> * Rename tupledesc and tructTupledesc to leafTupdesc and
> nonLeafTupdesc correspondingly. I think this makes things more clear.
> * Some improvements to docs and comments.
> * Revise commit
On Sat, 9 Mar 2019 at 13:18, David Rowley wrote:
> This is something I'd like to look into for v13. I think it'll be
> much easier to do if we can get your List reimplementation patch in
> first. That's going to allow list_nth on PlannerInfo->eq_classes to
> work quickly and will remove the need
for example:
begin;
declare cur cursor for select * from t;
insert into t2 values(...);
fetch next cur;
commit;
// after this, I can't fetch cur any more.
My question are:
1. Is this must in principle? or it is easy to implement as this in PG?
2. Any bad thing would happen if I keep the
69 matches
Mail list logo
