Michael Paquier wrote:
> On Thu, Sep 28, 2017 at 12:06 AM, Alvaro Herrera
> wrote:
>> I think the passwordcheck module as a whole is a dead end, security-
>> wise. Myself, I've never seen the point in it. It runs at the wrong
>> time, and there's no way to fix that.
>
> Client commands may be
- Run pgbench -c 10 -T 100
- Stop postgres with -m immediate
That is a strange test to run, but it would be better if the behavior was
not that one.
Well, I think it's a very legitimate test, not for testing performance, but
testing crash recovery and I use it very often.
Ok, interesting.
On Fri, Sep 29, 2017 at 2:19 PM, Kyotaro HORIGUCHI
wrote:
> It would practically work but I don't like the fact that the
> patch relies on the specific directory/file ordering in the tar
> stream. This is not about the CATVER directory but lower
> directories. Being more strict, it actually makes
On Fri, Sep 29, 2017 at 6:39 AM, Alvaro Herrera wrote:
> Peter Geoghegan wrote:
>
>> We certainly do still see wrong answers to queries here:
>>
>> postgres=# select ctid, xmin, xmax, * from t;
>> ctid | xmin | xmax | id | name | x
>> ---+---+--++--+---
>> (0,1) | 21171 |
On Fri, Sep 29, 2017 at 1:03 AM, Fabien COELHO wrote:
>
> The commit that introduced this code is 12788ae49e1933f463bc. So I amn
>>> copying Heikki.
>>>
>>
>> AFAICR the commit was mostly a heavy restructuring of previous
>> unmaintainable spaghetti code. I'm not sure the problem was not there
>>
On Fri, Sep 29, 2017 at 12:22 AM, Fabien COELHO wrote:
>
> While running some tests, I encountered a situation where pgbench gets
>> stuck in an infinite loop, consuming 100% cpu. The setup was:
>>
>> - Start postgres server from the master branch
>> - Initialise pgbench
>> - Run pgbench -c 10 -T
Hi,
At Tue, 19 Sep 2017 17:07:10 +0200, Pierre Ducroquet
wrote in <1678633.OBaBNztJnJ@pierred-pdoc>
> On Tuesday, September 19, 2017 12:52:37 PM CEST you wrote:
> > On Thu, Sep 14, 2017 at 2:17 AM, Pierre Ducroquet
> wrote:
> > > All my apologies for the schockingly long time with no answer on
Hi,
On Sat, Sep 9, 2017 at 1:29 PM, Haribabu Kommi
wrote:
>
> Fixed patch is attached.
>
Patch applies and has lot of noise due to indent with spaces.
I did ran regression tests located in - src/test/regress,
src/test/modules/test_pg_dump, src/bin/pg_dump, src/bin/pg_upgrade folders
and no is
On 2017-09-28 20:56:57 -0700, Andres Freund wrote:
> +1, I saw the same in a bleeding edge c++ version.
err, gcc version.
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
On 2017-09-28 20:01:37 -0400, Tom Lane wrote:
> I wondered how pervasive this behavior is. AFAICS it is *not* required
> by the C standard; C99 does not say that the left operand of assignment
> must be evaluated first, in fact it says that the order of evaluation is
> unspecified.
FWIW, it's bei
On Fri, Sep 29, 2017 at 4:17 PM, Michael Paquier
wrote:
>> As for DSM, I think that that can come later, and can be written by
>> somebody closer to that problem. There can be more than one
>> initialization function.
>
> I don't completely disagree with that, there could be multiple
> initializat
On Thu, Sep 28, 2017 at 3:32 AM, Peter Geoghegan wrote:
> On Wed, Sep 27, 2017 at 1:45 AM, Michael Paquier
> wrote:
>> I have signed up as a reviewer of this patch, and I have looked at the
>> bloom filter implementation for now. This is the kind of facility that
>> people have asked for on this
On 9/28/17, 8:46 PM, "Michael Paquier" wrote:
> On Fri, Sep 29, 2017 at 10:44 AM, Tom Lane wrote:
>> Michael Paquier writes:
>>> On Fri, Sep 29, 2017 at 2:44 AM, Bossart, Nathan
>>> wrote:
Alright, I've added logging for autovacuum in v23. I ended up needing to
do a little restructu
On Fri, Sep 29, 2017 at 1:53 AM, Konstantin Knizhnik
wrote:
> In Postgres 10 we have txid_status function which returns status of
> transaction by XID.
> I wonder if it will be also useful to have similar function for 2PC
> transactions which can operate with GID?
> pg_prepared_xacts view allows t
On Fri, Sep 29, 2017 at 10:44 AM, Tom Lane wrote:
> Michael Paquier writes:
>> On Fri, Sep 29, 2017 at 2:44 AM, Bossart, Nathan wrote:
>>> Alright, I've added logging for autovacuum in v23. I ended up needing to
>>> do a little restructuring to handle the case when the relation was skipped
>>>
Michael Paquier writes:
> On Fri, Sep 29, 2017 at 2:44 AM, Bossart, Nathan wrote:
>> Alright, I've added logging for autovacuum in v23. I ended up needing to
>> do a little restructuring to handle the case when the relation was skipped
>> because the lock could not be obtained. While doing so,
On 2017/09/28 22:19, Maksim Milyutin wrote:
> I also noticed ambiguity in printing "No partition constraint" in
> non-verbose mode and "Partition constraint:..." in verbose one for
> partition tables regardless of the type of partition.
> Attached small patch removes any output about partition cons
On 2017/09/28 22:29, Jesper Pedersen wrote:
> On 09/28/2017 09:19 AM, Maksim Milyutin wrote:
>>> E.g. "No partition constraint" vs. "Partition constraint:
>>> satisfies_hash_partition(...)".
>>
>> I also noticed ambiguity in printing "No partition constraint" in
>> non-verbose mode and "Partition c
On Fri, Sep 29, 2017 at 2:44 AM, Bossart, Nathan wrote:
> Alright, I've added logging for autovacuum in v23. I ended up needing to
> do a little restructuring to handle the case when the relation was skipped
> because the lock could not be obtained. While doing so, I became
> convinced that LOG
Andres Freund writes:
> On 2017-09-28 18:39:03 -0400, Tom Lane wrote:
>> + * Note: the reason for using a temporary variable "d", here
>> and in
>> + * other places, is that some compilers think "*op->resvalue =
>> f();"
>> + * requires them to evaluate op->re
Andres Freund writes:
> On 2017-09-28 18:52:28 -0400, Tom Lane wrote:
>> Uh, what? Access to fmgr_nbuiltins shouldn't be part of any critical path
>> anymore after this change.
> Indeed. But the size of the the oid -> fmgr_builtins index array is
> relevant now. We could of course just make that
On Thu, Sep 28, 2017 at 2:22 PM, Alexander Korotkov <
a.korot...@postgrespro.ru> wrote:
> On Fri, Jul 28, 2017 at 7:58 AM, Shubham Barai
> wrote:
>
>> I am attaching a patch for predicate locking in SP-Gist index
>>
>
> I took a look over this patch.
>
> newLeafBuffer = SpGistGetBuffer(index,
>>
On 2017-09-28 18:52:28 -0400, Tom Lane wrote:
> Andres Freund writes:
> > I might be worse than you... But anyway, here's a patch doing
> > so. Looking at profiles, it turned out that having the integer limits as
> > extern variables in a different TU isn't a great idea.
>
> Uh, what? Access to
Andres Freund writes:
> I might be worse than you... But anyway, here's a patch doing
> so. Looking at profiles, it turned out that having the integer limits as
> extern variables in a different TU isn't a great idea.
Uh, what? Access to fmgr_nbuiltins shouldn't be part of any critical path
anym
On 2017-09-28 18:39:03 -0400, Tom Lane wrote:
> Andres Freund writes:
> > On 2017-09-28 16:21:34 -0400, Tom Lane wrote:
> >> We could save a pointless register spill
> >> and reload if there were a temporary variable in there,
>
> > Makes sense. Do you want to make it so, or shall I?
>
> I just
On Thu, Sep 28, 2017 at 3:18 PM, Robert Haas wrote:
> On Fri, Jul 14, 2017 at 6:20 PM, Peter Geoghegan wrote:
>> With the additional enhancements made to Postgres 10, I doubt that
>> there are any remaining cases where it wins.
>
> I tried my favorite sorting test case -- pgbench -i -s 300 and th
Andres Freund writes:
> On 2017-09-28 16:21:34 -0400, Tom Lane wrote:
>> We could save a pointless register spill
>> and reload if there were a temporary variable in there,
> Makes sense. Do you want to make it so, or shall I?
I just finished testing a patch, as attached. On my machine (again,
On Thu, Sep 28, 2017 at 3:20 PM, Robert Haas wrote:
> On Thu, Sep 28, 2017 at 5:47 PM, Peter Geoghegan wrote:
>> In the end, commit 6bfa88a fixed that old recovery bug by making sure
>> the recovery routine heap_xlog_lock() did the right thing. In both
>> cases (Feb 2014 and today), the index was
On Thu, Sep 28, 2017 at 5:47 PM, Peter Geoghegan wrote:
> In the end, commit 6bfa88a fixed that old recovery bug by making sure
> the recovery routine heap_xlog_lock() did the right thing. In both
> cases (Feb 2014 and today), the index wasn't really corrupt -- it just
> pointed to the root of a H
On Fri, Jul 14, 2017 at 6:20 PM, Peter Geoghegan wrote:
> With the additional enhancements made to Postgres 10, I doubt that
> there are any remaining cases where it wins.
I tried my favorite sorting test case -- pgbench -i -s 300 and then
reindex index pgbench_accounts_pkey. I set maintenance_w
Hi,
On 2017-09-28 16:21:34 -0400, Tom Lane wrote:
> I noticed the following while poking around with perf:
>
>| fcinfo->isnull = false;
>|b5b: movb $0x0,0x1c(%rdx)
>| *op->resvalue =
> op->d.func.fn_addr(fcinfo);
On Thu, Sep 28, 2017 at 2:47 PM, Peter Geoghegan wrote:
> In the end, commit 6bfa88a fixed that old recovery bug by making sure
> the recovery routine heap_xlog_lock() did the right thing. In both
> cases (Feb 2014 and today), the index wasn't really corrupt -- it just
> pointed to the root of a H
On 2017-09-27 15:50:05 -0400, Tom Lane wrote:
> ISTM it shouldn't be that hard to get Gen_fmgrtab.pl to emit an index
> array of the sort we're talking about, along with the FmgrBuiltin array
> it already prints out. I'm the world's worst Perl programmer but
> I'm happy to take a stab at it if you
On Thu, Sep 28, 2017 at 2:39 PM, Alvaro Herrera wrote:
>> FWIW, I am reminded a little bit of the MultiXact/recovery bug I
>> reported way back in February of 2014 [1], which also had a HOT
>> interaction that caused index scans to give wrong answers, despite
>> more or less structurally sound ind
Andrew Dunstan writes:
> On 09/28/2017 01:11 PM, Tom Lane wrote:
>>> I wonder if we need to do any benchmarking to assure ourselves that the
>>> changes to ArrayCoerceExpr don't have a significant performance impact?
>> That would likely be a good idea, though I'm not very sure what or
>> how to
Peter Geoghegan wrote:
> We certainly do still see wrong answers to queries here:
>
> postgres=# select ctid, xmin, xmax, * from t;
> ctid | xmin | xmax | id | name | x
> ---+---+--++--+---
> (0,1) | 21171 |0 | 1 | 111 | 0
> (0,7) | 21177 |0 | 3 | 333 | 5
> (2
On Thu, Sep 28, 2017 at 10:52 PM, chenhj wrote:
> On 2017-09-29 00:43:18，"Alexander Korotkov"
> wrote:
>
> On Thu, Sep 28, 2017 at 6:44 PM, chenhj wrote:
>
>> On 2017-09-28 01:29:29，"Alexander Korotkov"
>> wrote:
>>
>> It appears that your patch conflicts with fc49e24f. Please, rebase it.
>>
On Thu, Sep 28, 2017 at 1:20 PM, Alvaro Herrera wrote:
> Alvaro Herrera wrote:
>
>> Odd that it's not fixed. I guess there's still some more work to do
>> here ...
>
> Maybe what this means is that we need to do both Dan's initially
> proposed patch (or something related to it) apart from the fix
On 09/28/2017 10:10 PM, Robert Haas wrote:
On Wed, Sep 13, 2017 at 7:00 AM, Simon Riggs wrote:
If we do have an option it won't be using fancy mathematical
terminology at all, it would be described in terms of its function,
e.g. recheck_on_update
+1.
I have nothing against renaming "projecti
On Thu, May 25, 2017 at 7:30 PM, Konstantin Knizhnik
wrote:
> Right now Postgres determines whether update operation touch index or not
> based only on set of the affected columns.
> But in case of functional indexes such policy quite frequently leads to
> unnecessary index updates.
> For example,
Hi
The plpgsql_check is mature project now, and I am would to start discussion
about future of this project. It is still private project, although it is
important for one from key PostgreSQL feature - PLpgSQL. I would be happy
if the community can take some responsibility for this project. This
pr
I noticed the following while poking around with perf:
| fcinfo->isnull = false;
|b5b: movb $0x0,0x1c(%rdx)
| *op->resvalue = op->d.func.fn_addr(fcinfo);
0.02 | mov0x8(%rbx),%rcx
1.19 | mov%rdx
Alvaro Herrera wrote:
> Odd that it's not fixed. I guess there's still some more work to do
> here ...
Maybe what this means is that we need to do both Dan's initially
proposed patch (or something related to it) apart from the fixes already
pushed. IOW we need to put back some of the "tupkeep"
Peter Geoghegan wrote:
> On Thu, Sep 28, 2017 at 7:47 AM, Alvaro Herrera
> wrote:
> > Fix freezing of a dead HOT-updated tuple
>
> If I run Dan Wood's test case again, the obvious symptom (spurious
> duplicates) goes away. However, the enhanced amcheck, and thus CREATE
> INDEX/REINDEX, still isn
On 2017-09-29 00:43:18，"Alexander Korotkov" wrote:
On Thu, Sep 28, 2017 at 6:44 PM, chenhj wrote:
On 2017-09-28 01:29:29，"Alexander Korotkov" wrote:
It appears that your patch conflicts with fc49e24f. Please, rebase it.
Yes, i had rebased it, Please check the new patch.
Good, now it ap
Hi,
In a case of
initdb /tmp/pgsql
followed by
pg_ctl -D /tmp/pgsql/ -l /tmp/logfile restart
you'll get
pg_ctl: PID file "/tmp/pgsql/postmaster.pid" does not exist
Is server running?
starting server anyway
pg_ctl: could not read file "/tmp/pgsql/postmaster.opts"
The attached patch changes t
The commit that introduced this code is 12788ae49e1933f463bc. So I amn
copying Heikki.
AFAICR the commit was mostly a heavy restructuring of previous unmaintainable
spaghetti code. I'm not sure the problem was not there before under one form
or another.
I agree that it should error out & s
On Wed, Sep 13, 2017 at 7:00 AM, Simon Riggs wrote:
> If we do have an option it won't be using fancy mathematical
> terminology at all, it would be described in terms of its function,
> e.g. recheck_on_update
+1.
> Yes, I'd rather not have an option at all, just some simple code with
> useful e
Andrew Dunstan writes:
> On 09/28/2017 01:02 PM, Tom Lane wrote:
>>> I do think that treating a function returning a domain-over-composite
>>> differently from one returning a base composite is a POLA. We'd be very
>>> hard put to explain the reasons for it to an end user.
>> Do you have any thou
I wrote:
> [ we should use an index array ]
Just to prove the point, I threw together the attached trivial test case,
which time-trials the existing fmgr_isbuiltin implementation against both
the proposed hash implementation and a simple index array. On my machine,
with a repeat count of 1, I
On 09/28/2017 01:02 PM, Tom Lane wrote:
>
>> I do think that treating a function returning a domain-over-composite
>> differently from one returning a base composite is a POLA. We'd be very
>> hard put to explain the reasons for it to an end user.
> Do you have any thoughts about how we ought to
While running some tests, I encountered a situation where pgbench gets
stuck in an infinite loop, consuming 100% cpu. The setup was:
- Start postgres server from the master branch
- Initialise pgbench
- Run pgbench -c 10 -T 100
- Stop postgres with -m immediate
That is a strange test to run,
On 09/28/2017 01:11 PM, Tom Lane wrote:
>
>> I wonder if we need to do any benchmarking to assure ourselves that the
>> changes to ArrayCoerceExpr don't have a significant performance impact?
> That would likely be a good idea, though I'm not very sure what or
> how to benchmark.
>
>
Marko Tiikkaja writes:
> On Wed, Sep 27, 2017 at 5:45 PM, Tom Lane wrote:
>> Looking at it another way, the main thing that the combination of hashagg
>> outer path + indexscan inner path knows that eqjoinsel_semi didn't account
>> for is that there's a unique index on foo.id. But that info is a
Andrew Dunstan writes:
> On 08/11/2017 01:17 PM, Tom Lane wrote:
>> Attached is a patch series that allows us to create arrays of domain
>> types.
> I've reviewed and tested the updated versions of these patches. The
> patches apply but there's an apparent typo in arrayfuncs.c -
> DatumGetAnyArra
Andrew Dunstan writes:
> On 07/13/2017 03:19 PM, Tom Lane wrote:
>> Attached is a draft patch that allows domains over composite types.
>> I think it's probably complete on its own terms, but there are some
>> questions around behavior of functions returning domain-over-composite
>> that could use
Hi,
In Postgres 10 we have txid_status function which returns status of
transaction by XID.
I wonder if it will be also useful to have similar function for 2PC
transactions which can operate with GID?
pg_prepared_xacts view allows to get information about prepared
transaction which are not yet
On Thu, Sep 28, 2017 at 6:44 PM, chenhj wrote:
> On 2017-09-28 01:29:29，"Alexander Korotkov"
> wrote:
>
> It appears that your patch conflicts with fc49e24f. Please, rebase it.
>
>
> Yes, i had rebased it, Please check the new patch.
>
Good, now it applies cleanly.
else if (strncmp(path, XLOG
On 09/28/2017 12:29 PM, Andrew Dunstan wrote:
> The new crash-recovery check is failing pretty reliably on jacana. It's
> already excluded on MSVC machines, so I'm inclined to exclude it on Msys
> as well.
>
>
Sorry, I meant crash-restart
cheers
andrew
--
Andrew Dunstanhttps:
The new crash-recovery check is failing pretty reliably on jacana. It's
already excluded on MSVC machines, so I'm inclined to exclude it on Msys
as well.
Thoughts?
cheers
andrew
--
Andrew Dunstanhttps://www.2ndQuadrant.com
PostgreSQL Development, 24x7 Support, Remote DBA,
On 2017-09-28 01:29:29，"Alexander Korotkov" wrote:
It appears that your patch conflicts with fc49e24f. Please, rebase it.
--
Alexander Korotkov
Postgres Professional: http://www.postgrespro.com
The Russian Postgres Company
Yes, i had rebased it, Please check the new patch.
-
On 07/13/2017 03:19 PM, Tom Lane wrote:
> I wrote:
>> I started to look into allowing domains over composite types, which is
>> another never-implemented case that there's no very good reason not to
>> allow. Well, other than the argument that the SQL standard only allows
>> domains over "predef
Hi Ashutosh,
Thanks for the review.
*Jeff*, I'm copying you because this is relevant to our discussion about
what to do with mergeopfamilies when adding new merge join types.
You have renamed RestrictInfo member mergeopfamilies as
equivopfamilies. I don't think that's a good name; it doesn't
On 28.09.2017 16:29, Jesper Pedersen wrote:
On 09/28/2017 09:19 AM, Maksim Milyutin wrote:
E.g. "No partition constraint" vs. "Partition constraint:
satisfies_hash_partition(...)".
I also noticed ambiguity in printing "No partition constraint" in
non-verbose mode and "Partition constraint:..
On 09/28/2017 09:19 AM, Maksim Milyutin wrote:
E.g. "No partition constraint" vs. "Partition constraint:
satisfies_hash_partition(...)".
I also noticed ambiguity in printing "No partition constraint" in
non-verbose mode and "Partition constraint:..." in verbose one for
partition tables regard
Hi!
On 28.09.2017 16:02, Jesper Pedersen wrote:
Hi,
Using hash partitions I noticed that \d gives
D=# \d T_p63
Table "public.T_p63"
Column | Type | Collation | Nullable | Default
---+---+---+--+-
Partition of:
Hi,
Using hash partitions I noticed that \d gives
D=# \d T_p63
Table "public.T_p63"
Column | Type | Collation | Nullable | Default
---+---+---+--+-
Partition of: T FOR VALUES WITH (modulus 64, remainder 63)
No par
On Sun, 3 Sep 2017 22:47:10 +0200
Daniel Gustafsson wrote:
I have reviewed your latest patch.
I can apply this to the master branch and build this successfully,
and the behavior is as expected.
However, here are some comments and suggestions.
> 135 + char *buffer = palloc0(MA
Hello,
While running some tests, I encountered a situation where pgbench gets
stuck in an infinite loop, consuming 100% cpu. The setup was:
- Start postgres server from the master branch
- Initialise pgbench
- Run pgbench -c 10 -T 100
- Stop postgres with -m immediate
Now it seems that pgbench g
Hi,
Commit 7086be6e3627c1ad797e32ebbdd232905b5f577f addressed mishandling of
WCO in direct foreign table modification by disabling it when we have
WCO, but I noticed another oddity in postgres_fdw:
postgres=# create table base_tbl (a int, b int);
postgres=# create function row_before_insupd_t
Hi!
On Fri, Jul 28, 2017 at 7:58 AM, Shubham Barai
wrote:
> I am attaching a patch for predicate locking in SP-Gist index
>
I took a look over this patch.
newLeafBuffer = SpGistGetBuffer(index,
> GBUF_LEAF | (isNulls ? GBUF_NULLS : 0),
> Min(totalLeafSizes,
> SPGIST_PAGE_CAPACITY),
> &xlrec.in
Hi!
On Wed, Jun 21, 2017 at 10:52 AM, Shubham Barai
wrote:
> Hi,
>
> On 21 June 2017 at 13:11, Heikki Linnakangas wrote:
>
>> On 06/16/2017 01:24 PM, Shubham Barai wrote:
>>
>>> @@ -497,6 +499,13 @@ gistplacetopage(Relation rel, Size freespace,
>>> GISTSTATE *giststate,
>>>
On Thu, Sep 28, 2017 at 12:45 AM, Alexander Korotkov <
a.korot...@postgrespro.ru> wrote:
> On Wed, Aug 9, 2017 at 6:30 PM, Shubham Barai
> wrote:
>
>> Please find the updated patch for predicate locking in gin index here.
>>
>> There was a small issue in the previous patch. I didn't consider the
On 20 September 2017 at 11:32, Amit Khandekar wrote:
> There is still the open point being
> discussed : whether to have non-parallel-aware partial Append path, or
> always have parallel-aware Append paths.
Attached is the revised patch v16. In previous versions, we used to
add a non-parallel-awa
On Thu, Sep 28, 2017 at 11:24 AM, Amit Langote
wrote:
> On 2017/09/27 22:41, Jesper Pedersen wrote:
>> On 09/27/2017 03:05 AM, amul sul wrote:
> Attached rebased patch, thanks.
>
>
While reading through the patch I thought it would be better to keep
MODULUS and REMAINDER in c
On Wed, Sep 27, 2017 at 3:42 PM, Jeevan Chalke
wrote:
> Thanks Ashutosh for reviewing.
>
> Attached new patch-set with following changes:
>
> 1. Removed earlier 0007 and 0008 patches which were PoC for supporting
> partial aggregation over fdw. I removed them as it will be a different
> issue alto
On 27 September 2017 at 14:22, Amit Langote
wrote:
> - 0001 includes refactoring that Dilip proposed upthread [1] (added him as
> an author). I slightly tweaked his patch -- renamed the function
> get_matching_clause to match_clauses_to_partkey, similar to
> match_clauses_to_index.
Hi Amit
On Thu, Sep 28, 2017 at 1:44 PM, Amit Langote
wrote:
> On 2017/09/28 13:58, Dilip Kumar wrote:
>> I think the above logic is common between this patch and the runtime
>> pruning. I think we can make
>> a reusable function. Here we are preparing minkey and maxkey of Datum
>> because we can direc
On 2017/09/28 13:58, Dilip Kumar wrote:
> On Wed, Sep 27, 2017 at 6:52 AM, Amit Langote
> wrote:
>
> I was looking into the latest patch set, seems like we can reuse some
> more code between this path and runtime pruning[1]
>
> + foreach(lc1, matchedclauses[i])
> + {
> + Expr *clause = lfirst(
On 2017/09/28 16:13, Ashutosh Bapat wrote:
> On Thu, Sep 28, 2017 at 11:47 AM, Amit Langote wrote:
>> On 2017/09/21 12:42, Robert Haas wrote:
>>> Associate partitioning information with each RelOptInfo.
>>>
>>> This is not used for anything yet, but it is necessary infrastructure
>>> for partition-
On Thu, Sep 28, 2017 at 11:47 AM, Amit Langote
wrote:
> On 2017/09/21 12:42, Robert Haas wrote:
>> Associate partitioning information with each RelOptInfo.
>>
>> This is not used for anything yet, but it is necessary infrastructure
>> for partition-wise join and for partition pruning without const
Below are some performance figures. Overall, there does not appear to
be a noticeable difference in the figures in partition key updates
with and without row movement (which is surprising), and
non-partition-key updates with and without the patch.
All the values are in milliseconds.
Configuration
Thanks Michael for working on this.
On 2017/09/27 11:28, Michael Paquier wrote:
> Hi all,
>
> I have been looking more closely at the problem in $subject, that I
> have mentioned a couple of times, like here:
> https://www.postgresql.org/message-id/cab7npqqa37oune_rjzpmwc4exqalx9f27-ma_-rsfl_3mj+
83 matches
Mail list logo
