On 4 July 2018 at 13:48, Michael Paquier wrote:
> So at the end I have dropped the table from the test, and pushed the
> patch to HEAD and REL_11_STABLE. Thanks David for the patch, and others
> for the reviews.
Thanks for pushing it.
--
David Rowley http://www.2ndQuadrant.
On Tue, Jul 03, 2018 at 08:31:27PM +0900, Michael Paquier wrote:
> I am not sure if it is much interesting to keep around this table set
> for pg_upgrade, so I would drop it. Except for that, the result looks
> fine. I'll double-check and wrap it tomorrow on HEAD and REL_11_STABLE.
> The optimiza
Remove dead code for temporary relations in partition planning
Since recent commit 1c7c317c, temporary relations cannot be mixed with
permanent relations within the same partition tree, and the same counts
for temporary relations created by other sessions, which the planner
simply discarded. Inst
Remove dead code for temporary relations in partition planning
Since recent commit 1c7c317c, temporary relations cannot be mixed with
permanent relations within the same partition tree, and the same counts
for temporary relations created by other sessions, which the planner
simply discarded. Inst
On 2018/07/04 1:21, Tom Lane wrote:
> Ashutosh Bapat writes:
>> On Tue, Jul 3, 2018 at 3:20 PM, Amit Langote
>> wrote:
>>> Maybe because that's what's done for the root parent in a plain
>>> inheritance hierarchy, which is always a plain table. In that case, one
>>> RTE is for its role as the pa
On 2018/07/03 21:15, Ashutosh Bapat wrote:
> On Tue, Jul 3, 2018 at 3:20 PM, Amit Langote
> wrote:
>>
>> Maybe because that's what's done for the root parent in a plain
>> inheritance hierarchy, which is always a plain table. In that case, one
>> RTE is for its role as the parent (with rte->inh =
On Tue, Jul 03, 2018 at 04:12:23PM -0400, Alvaro Herrera wrote:
> On 2018-Jul-03, Andres Freund wrote:
>
> > On 2018-07-03 15:13:20 -0400, Alvaro Herrera wrote:
> > > Are the numerical values actually exposed to the world? I thought the
> > > only way to this info was through the system views, wh
Add $Test::Builder::Level to pgbench test functions
same as c4309f4aeeae54e4c5281d68e29288af1d0d1ed2
Branch
--
master
Details
---
https://git.postgresql.org/pg/commitdiff/2c059c86ba774930fa816278343ff30292db4e6c
Modified Files
--
src/bin/pgbench/t/001_pgbench_with_server.pl
On 2018-Jul-03, Andres Freund wrote:
> On 2018-07-03 15:13:20 -0400, Alvaro Herrera wrote:
> > Are the numerical values actually exposed to the world? I thought the
> > only way to this info was through the system views, which surely expose
> > the names, not the numbers.
>
> There's at least so
Hi,
On 2018-07-03 15:13:20 -0400, Alvaro Herrera wrote:
> Are the numerical values actually exposed to the world? I thought the
> only way to this info was through the system views, which surely expose
> the names, not the numbers.
There's at least some work at high frequency sampling of these,
On 2018-Jul-03, Michael Paquier wrote:
> On Mon, Jul 02, 2018 at 12:23:35PM -0400, Alvaro Herrera wrote:
> > I wonder if we should backpatch this one all the way to pg10. I don't
> > see no reason not to.
>
> ABI breakage (if that's the correct wording?). Simply cherry-picking
> the patch from
Correct comment
Branch
--
master
Details
---
https://git.postgresql.org/pg/commitdiff/683707868723d2a798ff8dcb0513d89735591b66
Modified Files
--
src/bin/pgbench/t/001_pgbench_with_server.pl | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
Correct comment
Branch
--
REL_11_STABLE
Details
---
https://git.postgresql.org/pg/commitdiff/31658f794370547eb19b233956afe92a07cd6fdd
Modified Files
--
src/bin/pgbench/t/001_pgbench_with_server.pl | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
Ashutosh Bapat writes:
> On Tue, Jul 3, 2018 at 3:20 PM, Amit Langote
> wrote:
>> Maybe because that's what's done for the root parent in a plain
>> inheritance hierarchy, which is always a plain table. In that case, one
>> RTE is for its role as the parent (with rte->inh = true) and another is
On Tue, Jul 3, 2018 at 3:20 PM, Amit Langote
wrote:
>
> Maybe because that's what's done for the root parent in a plain
> inheritance hierarchy, which is always a plain table. In that case, one
> RTE is for its role as the parent (with rte->inh = true) and another is
> for its role as a child (wi
On 17.06.18 11:02, Michael Paquier wrote:
> Here is a trick I have learnt to use with my emacs configuration for
> commit messages:
> ;; Git settings: auto-fill-mode for commits with dedicated mode.
> (define-derived-mode git-commit-mode text-mode "GitCommit"
A git-commit-mode already exists. It
On Tue, Jul 03, 2018 at 11:16:55PM +1200, David Rowley wrote:
> Oh okay. Yeah, you can hit that with a partitionless sub-partitioned
> table.
Thanks for the patch and fixing the typo ;)
+create table list_parted_tbl (a int,b int) partition by list (a);
+create table list_parted_tbl1 partition of
On 3 July 2018 at 21:53, Michael Paquier wrote:
> Your patch removes this part:
> - /*
> -* If the partitioned table has no partitions or all the partitions are
> -* temporary tables from other backends, treat this as non-inheritance
> -* case.
> -*/
> - if (!has_child)
> -
On Tue, Jul 03, 2018 at 09:30:20PM +1200, David Rowley wrote:
> On 3 July 2018 at 21:15, Michael Paquier wrote:
> > Yeah. Actually I'd like to add a test as well to test the recursion
> > call of expand_partitioned_rtentry. If you have an idea, please let me
> > know or I'll figure out one by my
On 2018/07/03 18:05, David Rowley wrote:
> (re-adding committers list)
>
> On 3 July 2018 at 20:31, Amit Langote wrote:
>> 1. I still insist that it's better for the newly added code to be near the
>> top of the function body than in the middle, which brings me to...
>
> That will cause the Appe
On 3 July 2018 at 21:15, Michael Paquier wrote:
> Yeah. Actually I'd like to add a test as well to test the recursion
> call of expand_partitioned_rtentry. If you have an idea, please let me
> know or I'll figure out one by myself and add it probably in
> create_table.sql.
What specifically do
On Tue, Jul 03, 2018 at 09:05:41PM +1200, David Rowley wrote:
>
> [...]
>
> I'd categorise this one the same as I have #1 above, i.e. not
> backpatch material. It seems like something useful to look into for
> v12 though. I assumed this was done for a reason and that I just
> didn't understand what
(re-adding committers list)
On 3 July 2018 at 20:31, Amit Langote wrote:
> 1. I still insist that it's better for the newly added code to be near the
> top of the function body than in the middle, which brings me to...
That will cause the AppendRelInfo not to be built for a partitioned
table wit
23 matches
Mail list logo
