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
>>
On 2018/12/17 15:52, Michael Paquier wrote:
> On Mon, Dec 17, 2018 at 03:40:28PM +0900, Michael Paquier wrote:
>> I was just going through some of the tests, when I noticed that the
>> tests of partition_info.sql have two typos and that the last set of
>> tests is imprecise about the expected
On 2018/12/10 0:57, Amit Langote wrote:
> On Sun, Dec 9, 2018 at 8:13 PM David Rowley
> wrote:
>> listp1 was scanned twice (loops=2), listp2 was scanned just once.
>>
>> Now it is true that if the subplan was executed 0 times that it will
>> appear as "(neve
Hi,
On 2018/12/15 8:00, Michael Paquier wrote:
> On Fri, Dec 14, 2018 at 05:21:49PM +0530, Suraj Kharage wrote:
>> There are some catalog views which do not show the partitioned table and
>> its index entry.
>> One of them is "pg_indexes" which failed to show the partitioned index.
>> Attached
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 pl
On 2018/11/09 14:04, Amit Langote wrote:
> On 2018/11/09 4:39, Alvaro Herrera wrote:
>> I included the test case for collations to the three branches, but no
>> code changes. We can patch master for the handling of collations per
>> your patch,
>
> Okay, but should
Hi,
On 2018/12/12 10:48, Michael Paquier wrote:
> On Fri, Dec 07, 2018 at 11:46:05AM +0900, Michael Paquier wrote:
>> On Thu, Dec 06, 2018 at 10:48:59PM -0300, Alvaro Herrera wrote:
>>> I think adding a pg_partition_root() call to as many pg_partition_tree
>>> tests as you modified is overkill
On 2018/11/29 19:54, David Rowley wrote:
> The problem is only made worse in PG11 from PG10
> because generating the custom plan has become faster than it
> previously was due to the new partition pruning code which might make
> it appear we can handle more partitions than we could previously,
Hi Michael,
On 2018/11/29 16:27, Michael Paquier wrote:
> Hi all,
>
> d5eec4ee has added pg_partition_tree, unfortunately it is not showing in
> the documentation index. Please see attached to fix the mistake.
Oh, I wasn't aware of this index and that the tag is meant for
that.
> Any
Hi,
On 2018/12/04 7:50, Alvaro Herrera wrote:
> While working on FKs pointing to partitioned tables, I noticed that in
> PG11 we fail to produce a working dump in the case of a partitioned
> table that doesn't have partitions.
>
> The attached patch fixes that.
The fix makes sense. I see that
On 2018/12/03 17:51, Magnus Hagander wrote:
> On Mon, Dec 3, 2018 at 7:39 AM Tatsuo Ishii wrote:
>>> Could we improve the error message that's output when the subscription
>>> target relation is a partitioned table? Currently, we get:
>>>
>>> ERROR: logical replication target relation
On 2018/12/04 11:23, Michael Paquier wrote:
> On Tue, Dec 04, 2018 at 10:51:40AM +0900, Amit Langote wrote:
>> Okay, here is a patch. I didn't find any tests in subscription.sql
>> related to unsupported relkinds, so didn't bother adding one for this case
>> either.
>
Hi,
Sorry for not replying sooner.
On Sat, Dec 8, 2018 at 8:06 Michael Paquier wrote:
> On Fri, Dec 07, 2018 at 10:04:06AM +0900, Michael Paquier wrote:
> > While testing another patch, I have bumped into the issue of
> > $subject... I should have put some more negative testing from the start
Hi,
Could we improve the error message that's output when the subscription
target relation is a partitioned table? Currently, we get:
ERROR: logical replication target relation "public.foo" is not a table
I think it'd be more helpful to get:
ERROR: "public.foo" is a partitioned table
DETAIL:
On 2018/12/06 11:28, Amit Langote wrote:
> On 2018/12/05 10:28, Amit Langote wrote:
>> On 2018/12/05 10:20, Michael Paquier wrote:
>>> On Tue, Dec 04, 2018 at 09:25:09AM +0100, Magnus Hagander wrote:
>>>> I think more people would directly understand the "is no
On 2018/12/06 11:14, Amit Langote wrote:
> I ran the original unmodified query at [1] (the one that produces an empty
> plan due to all children being pruned) against the server built with
> patches I posted on the "speeding up planning with partitions" [2] thread
> and
On 2018/12/05 10:28, Amit Langote wrote:
> On 2018/12/05 10:20, Michael Paquier wrote:
>> On Tue, Dec 04, 2018 at 09:25:09AM +0100, Magnus Hagander wrote:
>>> I think more people would directly understand the "is not a table" for a
>>> foreign table than a part
On 2018/12/05 16:23, Amit Langote wrote:
> Hi,
>
> Documentation of run-time pruning tells readers to inspect "nloops"
> property of the EXPLAIN ANALYZE output, but I think that's a typo of
> "loops" which is actually output ("internal variable t
On 2018/12/06 13:19, Michael Paquier wrote:
> On Thu, Dec 06, 2018 at 11:34:19AM +0900, Amit Langote wrote:
>> Adding to January CF.
>
> Okay, that looks good to me based on your arguments upthread.
Thanks for looking.
> A
> small-ish comment I have is that you could
Hi,
On 2018/12/05 6:55, Alvaro Herrera wrote:
> On 2018-Dec-04, Alvaro Herrera wrote:
>
>> CREATE TABLE precio(fecha timestamp, pluid int, loccd int, plusalesprice
>> int) PARTITION BY RANGE (fecha);
>> SELECT format('CREATE TABLE public.precio_%s PARTITION OF public.precio
>> (PRIMARY KEY
Hi,
(Re-sending after adding -hackers, sorry for the noise to those who would
receive this twice)
On 2018/12/05 6:55, Alvaro Herrera wrote:
> I noticed another interesting thing, which is that if I modify the query
> to actually reference some partition that I do have (as opposed to the
> above,
On Sun, Dec 9, 2018 at 8:13 PM David Rowley
wrote:
> listp1 was scanned twice (loops=2), listp2 was scanned just once.
>
> Now it is true that if the subplan was executed 0 times that it will
> appear as "(never executed)", but do we really need to explain in this
> area that "(never executed)"
On 2018/11/30 14:58, David Rowley wrote:
> On Fri, 30 Nov 2018 at 15:04, Amit Langote
> wrote:
>>
>> On 2018/11/29 19:54, David Rowley wrote:
>>> The problem is only made worse in PG11 from PG10
>>> because generating the custom plan has become faster than
On 2018/12/05 10:20, Michael Paquier wrote:
> On Tue, Dec 04, 2018 at 09:25:09AM +0100, Magnus Hagander wrote:
>> I think more people would directly understand the "is not a table" for a
>> foreign table than a partitioned one (for example, it does now show up in
>> \dt or under tables in pgadmin,
Hi,
Documentation of run-time pruning tells readers to inspect "nloops"
property of the EXPLAIN ANALYZE output, but I think that's a typo of
"loops" which is actually output ("internal variable to track that
property is indeed nloops).
However, for pruned partitions' subplans, what's actually
On 2018/11/20 15:58, Tom Lane wrote:
> Michael Paquier writes:
>> On Tue, Nov 20, 2018 at 02:00:39PM +0900, Amit Langote wrote:
>>> - * We also use EquivalenceClasses as the base structure for PathKeys,
>>> letting
>>> + * We also use EquivalenceClass as the
Hi,
On 2018/11/20 2:49, Jung, Jinho wrote:
> Execution time
> =
> 1.sql
> 10.6 : 469 ms
> 9.4.20: 10 ms
>
> 4.sql
> 10.6 : 34019 ms
> 9.4.20: 0.4 ms
I noticed that these two are fixed by running ANALYZE in the database in
which these queries are run.
> 20.sql
> 10.6 : 2791 ms
>
Hi,
It seems to me that EquivalenceClass, the struct/type name, has been
misspelled as 'EquivalenceClasses' a couple of times in the comment above
its definition.
Attached fixes that.
Thanks,
Amit
diff --git a/src/include/nodes/relation.h b/src/include/nodes/relation.h
index
Thank you for looking.
On 2018/11/20 14:13, Michael Paquier wrote:
> On Tue, Nov 20, 2018 at 02:00:39PM +0900, Amit Langote wrote:
>> It seems to me that EquivalenceClass, the struct/type name, has been
>> misspelled as 'EquivalenceClasses' a couple of times in the comment above
&g
On 2018/11/20 16:50, Michael Paquier wrote:
> Testing the feature, \dP shows all partitioned relations, still does not
> show the relationship when multiple levels are used. Could it make
> sense to also show the direct parent of a partitioned table when
> verbose mode is used?
Yeah. I think it
Sorry for jumping in late on this.
On 2018/11/24 1:25, Tom Lane wrote:
> David Rowley writes:
> Thinking more about this, the problem I noted previously about two of
> these solutions not working if the index scan node is not physically
> underneath the ModifyTable node actually applies to all
On 2018/11/09 14:38, Amit Langote wrote:
> Rebased due to change in addRangeTableEntryForRelation's API.
Rebased again due to changes in psql's describe output for partitioned tables.
Thanks,
Amit
>From 999aa53b459a6fc0fe899e613406f0e0035aca94 Mon Sep 17 00:00:00 2001
From: Kyotaro Hor
On 2018/11/26 14:25, David Rowley wrote:
> On Mon, 26 Nov 2018 at 17:37, Amit Langote
> wrote:
>> On 2018/11/24 1:25, Tom Lane wrote:
>>> I'm beginning to think that postponing target-index locking to
>>> ExecInitModifyTable was a damfool idea and we should undo it.
Hi Pavan,
Thanks for continuing to work on this.
On 2018/11/27 20:18, Pavan Deolasee wrote:
> Ok. I will try that approach again. In the meanwhile, I am posting a
> rebased version. There had been quite a lot changes on partitioning side
> and that caused non-trivial conflicts. I noticed a
Hi Kato-san,
On 2018/11/27 19:05, Kato, Sho wrote:
> Of course, in case of plan_cache_mode = force_custom_plan, it is not problem
> because unnecessary paths are pruned by speeding up planning with partitions
> patch[1].
>
> However, if plan_cachemode is force_generic_plan, generic plan is
On 2018/11/28 13:46, Amit Langote wrote:
> It's cheaper than using a cached generic plan (without re-planning),
> because the latter has to pay the cost of AcquireExecutorLocks which takes
> longer as the number of partitions increases. Perhaps something to try
> fix fixing too.
Hi,
On Thu, Nov 22, 2018 at 7:25 AM David Rowley
wrote:
>
> On Thu, 22 Nov 2018 at 07:06, Alvaro Herrera wrote:
> > On 2018-Nov-21, David Rowley wrote:
> > > If I wasn't on leave late last week and early this week then the only
> > > thing I'd have mentioned was the lack of empty comment line
On Tue, Nov 20, 2018 at 10:08 PM Jung, Jinho wrote:
> We are wondering how ANALYZE mitigated regression from query "1.sql" and
> "4.sql".
>
> We followed this procedure but still observe performance regression:
> 1) run ANALYZE on used table_name
> analyze pg_catalog.pg_ts_parser;
>
On 2018/11/27 6:19, David Rowley wrote:
> On Mon, 26 Nov 2018 at 18:57, Amit Langote
> wrote:
>> On 2018/11/26 14:25, David Rowley wrote:
>>> I'm making efforts to delay per-partition work even further in the
>>> executor, for example locking of the per-partition re
Hi,
On 2018/11/02 9:17, Haribabu Kommi wrote:
> Here I attached the cumulative fixes of the patches, new API additions for
> zheap and
> basic outline of the documentation.
I've read the documentation patch while also looking at the code and here
are some comments.
+ Each table is stored as
On 2018/11/19 11:17, Alvaro Herrera wrote:
> On 2018-Jul-23, Pavel Stehule wrote:
>
>> p.s. Another patch can be replacement of relation type from "table" to
>> "partitioned table"
>>
>> postgres=# \dt+
>> List of relations
>>
On 2018/11/17 9:06, Michael Paquier wrote:
> On Fri, Nov 16, 2018 at 09:38:40AM -0500, Robert Haas wrote:
>> OK, but it seems to me that your version of my patch rearranges the
>> code more than necessary.
>>
>> How about the attached?
>
> What you are proposing here looks good to me. Thanks!
Fujita-san,
(sorry about the repeated email, but my previous attempt failed due to
trying to send to the -hackers and -performance lists at the same time, so
trying again after removing -performance)
On 2019/01/08 20:07, Etsuro Fujita wrote:
> (2018/12/07 20:14), Ashutosh Bapat wrote:
>> On Fri,
Fujita-san,
On 2019/01/09 20:20, Etsuro Fujita wrote:
> (2019/01/09 9:30), Amit Langote wrote:
>> So, while the patch at [1] can take care of this issue as I also mentioned
>> upthread, I was trying to come up with a solution that can be back-patched
>> to PG 11. The patch
On 2019/01/10 14:25, Michael Paquier wrote:
> On Tue, Jan 08, 2019 at 04:42:35PM +0900, Michael Paquier wrote:
>> I can see your point, though I would stick with
>> ERRCODE_WRONG_OBJECT_TYPE for consistency with the existing code and
>> because the code is intended to not work on anything else
Hi,
On 2019/01/10 17:46, Arkhena wrote:
>> Your rewritten version is perhaps fine, although I remain a bit concerned
>> that some users might be puzzled when they see this error, that is, if
>> they interpret the message as "it's impossible to use a partitioned table
>> as logical replication
On Fri, Jan 11, 2019 at 12:58 AM Tom Lane wrote:
> Dean Rasheed writes:
> > The "Crash on ALTER TABLE" thread [1] started on -bugs, but Andrew's
> > message on 8 Jan with an initial proposed patch and my response later
> > that day both CC'ed -hackers and seem to have been rejected, and so
> >
On 2019/01/08 11:10, Michael Paquier wrote:
> On Mon, Jan 07, 2019 at 05:28:27PM +0900, Amit Langote wrote:
>> On 2019/01/07 16:35, Michael Paquier wrote:
>>> It seems to me that we may want something more like:
>>> Primary: "could not use \"%s.%s\"
Thanks Justin for reporting the results of your testing.
On 2019/01/07 17:40, David Rowley wrote:
> On Fri, 4 Jan 2019 at 04:39, Justin Pryzby wrote:
>> Running 11dev with your v10 patch applied, this takes 2244ms with empty
>> buffer
>> cache after postmaster restarted on a totally untuned
On 2019/01/08 13:44, Michael Paquier wrote:
> On Tue, Jan 08, 2019 at 01:13:11PM +0900, Amit Langote wrote:
>> Yeah, I think so too. I also noticed that the patch uses
>> ERRCODE_WRONG_OBJECT_TYPE as the error code, whereas we may want to use
>> ERRCODE_FEATURE_NOT
On 2019/01/07 16:35, Michael Paquier wrote:
> On Mon, Jan 07, 2019 at 01:49:49PM +0900, Amit Langote wrote:
>> {
>> /*
>> - * We currently only support writing to regular tables.
>> + * We currently only support writing to regular tables. However, give
On 2019/01/11 11:07, Amit Langote wrote:
> On 2019/01/11 6:47, David Rowley wrote:
>> On Fri, 11 Jan 2019 at 06:56, Alvaro Herrera
>> wrote:
>>> Pushed 0001 with some minor tweaks, thanks.
>>
>> Thanks for pushing. I had looked at 0001 last night and
On 2019/01/11 11:21, Etsuro Fujita wrote:
> (2019/01/10 21:23), Amit Langote wrote:
>> On Thu, Jan 10, 2019 at 6:49 PM Ashutosh Bapat
>> wrote:
>>> Though this will solve a problem for performance when partition-wise
>>> join is not possible, we still have th
Fujita-san,
On 2019/01/10 15:07, Etsuro Fujita wrote:
> Amit-san,
>
> (2019/01/10 10:41), Amit Langote wrote:
>> On 2019/01/09 20:20, Etsuro Fujita wrote:
>>> I like your patch in general. I think one way to address Ashutosh's
>>> concerns would be to use the
On 2019/01/10 19:27, Michael Paquier wrote:
> On Thu, Jan 10, 2019 at 05:58:10PM +0900, Amit Langote wrote:
>> The reason I started this thread is due to this Stack Overflow question:
>>
>> https://stackoverflow.com/questions/53554727/logical-replication-and-declarative-parti
On 2019/01/11 2:56, Alvaro Herrera wrote:
> On 2019-Jan-10, Amit Langote wrote:
>
>> Here's v12, which is more or less same as v11 but with the order of
>> patches switched so that the code movement patch is first. Note that the
>> attached v12-0001 contains no functio
Sorry, I hadn't read this email before sending my earlier "thank you for
committing" email.
On 2019/01/11 6:47, David Rowley wrote:
> On Fri, 11 Jan 2019 at 06:56, Alvaro Herrera wrote:
>> Pushed 0001 with some minor tweaks, thanks.
>
> Thanks for pushing. I had looked at 0001 last night and
On Wed, Jan 9, 2019 at 11:41 PM Alvaro Herrera wrote:
> > From 3b86331dd5a2368adc39c9fef92f3dd09d817a08 Mon Sep 17 00:00:00 2001
> > From: amit
> > Date: Wed, 7 Nov 2018 16:51:31 +0900
> > Subject: [PATCH v11 4/6] Move inheritance expansion code into its own file
>
> I wonder if it would make
Hi,
I noticed a couple of problems with foreign keys on partitioned tables.
1. Foreign keys of partitions stop working correctly after being detached
from the parent table
create table pk (a int primary key);
create table p (a int) partition by list (a);
create table p1 partition of p for
Thanks for reviewing.
On 2018/12/31 20:23, Peter Eisentraut wrote:
> On 06/12/2018 05:46, Amit Langote wrote:
>> /*
>> * We currently only support writing to regular tables.
>> */
>
> I think that comment should stay above the code you are a
On Wed, Sep 12, 2018 at 9:23 PM, Jesper Pedersen
wrote:
> Hi Amit,
>
> On 9/12/18 1:23 AM, Amit Langote wrote:
>>
>> Please find attached revised patches.
>>
>
> After applying 0004 I'm getting a crash in 'eval-plan-qual' during
> check-world using
>
>
On 2018/09/13 1:14, Tom Lane wrote:
> Amit Langote writes:
>> The infamous missing-relkind-check in heap_truncate() seems to be behind
>> this. Perhaps, a patch like the attached will do?
>
> That seems excessively restrictive. Anything that has storage (e
On 2018/09/13 12:37, Michael Paquier wrote:
> On Wed, Sep 12, 2018 at 12:14:00PM -0400, Tom Lane wrote:
>> I thought we had a macro or utility function somewhere that knew which
>> relkinds have storage, though I can't find it right now. I'd be
>> inclined to instantiate that if it doesn't exist,
On 2018/09/13 23:13, Tom Lane wrote:
> Amit Langote writes:
>> On 2018/09/13 1:14, Tom Lane wrote:
>>> That seems excessively restrictive. Anything that has storage (e.g.
>>> matviews) ought to be truncatable, no?
>
>> Not by heap_truncate it seems. The
On 2018/09/12 19:29, Rajkumar Raghuwanshi wrote:
> Hi,
>
> I am getting below error while creating temp root partition table with on
> commit. getting same error from v10 onwards.
>
> [edb@localhost bin]$ ./psql postgres
> psql (10.5)
> Type "help" for help.
>
> postgres=# CREATE TEMP TABLE
Hi,
On Sat, Jan 26, 2019 at 12:01 Michael Paquier wrote:
> On Sat, Jan 26, 2019 at 03:14:51AM +0900, Amit Langote wrote:
> > How about replacing \d+ list_parted with couple of \d on individual
> > partitions, like in the attached?
>
> That would make it. Why just par
Hi Peter,
On 2019/01/26 17:25, Peter Eisentraut wrote:
> On 25/01/2019 16:19, Tom Lane wrote:
>> Peter Eisentraut writes:
>>> committed
>>
>> Some of the buildfarm members are having sort-ordering problems
>> with this. Looks like you could work around it with different
>> partition names
On 2019/01/25 2:18, Alvaro Herrera wrote:
> On 2019-Jan-24, Amit Langote wrote:
>
>> A few hunks of the originally proposed patch are attached here as 0001,
>> especially the part which fixes ATAddForeignKeyConstraint to pass the
>> correct value of connoninherit to Crea
Imai-san,
Thanks for testing.
On 2019/01/24 15:09, Imai, Yoshikazu wrote:
> [pgbench commands]
> pgbench -n -f update.sql -T 30 postgres
>
> [update.sql(updating partkey case)]
> update rt set a = 1;
>
> [update.sql(updating non-partkey case)]
> update rt set b = 1;
>
> [results]
> updating
On 2019/01/28 10:26, David Rowley wrote:
> On Tue, 4 Dec 2018 at 00:42, David Rowley
> wrote:
>> Over here and along similar lines to the above, but this time I'd like
>> to take this even further and change things so we don't lock *any*
>> partitions during AcquireExecutorLocks() and instead
Hi David,
On 2019/01/28 13:18, David Rowley wrote:
> On Sat, 12 Jan 2019 at 02:00, Amit Langote wrote:
>> On 2019/01/09 9:09, David Rowley wrote:
>>> postgres=# update parent set c = c where a = 333;
>>> server closed the connection unexpectedly
>>>
On Tue, Jan 29, 2019 at 12:18 AM Tom Lane wrote:
> In the pluggable-storage discussion, there was some talk of renaming
> nodes/relation.h to avoid confusion with the new access/relation.h
> header. I think this is a fine idea, not only because of that conflict
> but because "relation.h" has
Hi Alvaro,
On 2019/04/02 5:03, Alvaro Herrera wrote:
> On 2019-Mar-29, Jesper Pedersen wrote:
>
>> I ran my test cases for this feature, and havn't seen any issues.
>>
>> Therefore I'm marking 1877 as Ready for Committer. If others have additional
>> feedback feel free to switch it back.
>
>
Thanks for taking a look.
On 2019/04/02 2:34, Tom Lane wrote:
> Amit Langote writes:
>> On 2019/03/30 0:29, Tom Lane wrote:
>>> That seems like probably an independent patch --- do you want to write it?
>
>> Here is that patch.
>> It revises get_relation_cons
Hi David,
On Tue, Apr 2, 2019 at 8:49 PM David Rowley
wrote:
> I ended up rewording the entire thing and working on the header
> comment for the function too. I think previously it wasn't that well
> defined what "ordered" meant. I added a mention that we expect that
> NULLs, if possible must
(I've closed the CF entry: https://commitfest.postgresql.org/22/1778/)
On 2019/04/01 2:04, Tom Lane wrote:
> Amit Langote writes:
>> On Sun, Mar 31, 2019 at 11:45 AM Imai Yoshikazu
>> wrote:
>>> Certainly, using bitmapset contributes to the performance when scanni
Hi Thomas,
Thanks for working on this.
On Mon, Apr 1, 2019 at 5:53 Thomas Munro wrote:
Hello,
>
> Building on the excellent work begun by commit e529cd4ffa60, I would
> like to propose a do-what-I-mean mode for psql. Please find a POC
> patch attached. It works like this:
>
> postgres=#
Hi Alvaro,
On 2019/04/03 4:42, Alvaro Herrera wrote:
> On 2019-Apr-02, Alvaro Herrera wrote:
>
>> Something is not right:
>
> Another thing that was not right is that translated_columns was being
> marked static, and modified in the function; so if you called \dP twice
> where one called for
On 2019/04/03 3:10, David Rowley wrote:
> On Wed, 3 Apr 2019 at 01:26, Amit Langote wrote:
>> +#include "nodes/pathnodes.h"
>> ...
>> +partitions_are_ordered(struct RelOptInfo *partrel)
>>
>> Maybe, "struct" is unnecessary?
>
> I just
On 2019/04/03 3:54, Erik Rijkers wrote:
> create schema if not exists "tmp";
> CREATE SCHEMA
> create server if not exists "tmpserver" foreign data wrapper file_fdw;
> CREATE SERVER
> drop foreign table if exists tmp.pg_head cascade;
> DROP FOREIGN TABLE
> create foreign table
Hosoya-san,
On 2019/04/02 14:02, Yuzuko Hosoya wrote:
> Hi,
>
>> Maybe we should have two patches as we seem to be improving two things:
>>
>> 1. Patch to fix problems with default partition pruning originally reported
>> by Hosoya-san
>>
>> 2. Patch to determine if a given clause contradicts a
Horiguchi-san,
Thanks for taking a look.
On 2019/04/03 12:02, Kyotaro HORIGUCHI wrote:
> \dPn doesn't show children because the are of 'r' relkind. And
> \dPn * doesn't show type for children.
>
> create table pa (a int, b int) partition by range (a);
> create table c1 partition of pa for
Hi,
On 2019/03/26 7:38, Alvaro Herrera wrote:
> v9 attached; this one's final AFAICT.
Agreed.
Thanks,
Amit
On 2019/03/26 1:53, Alvaro Herrera wrote:
> Here's v6 of this patch. I have rebased on top of today's CLUSTER
> monitoring, as well as on table AM commits. The latter caused a bit of
> trouble, as now the number of blocks processed by a scan is not as easy
> to get as before; I added a new entry
Hi,
On 2019/03/26 10:15, Michael Paquier wrote:
> Done as you suggested, with a minimal set enough to trigger the crash,
> still the error message is rather misleading as you would expect :)
Thanks for committing.
>> A separate thread will definitely attract more attention, at least in due
>>
On 2019/03/26 0:21, Robert Haas wrote:
> On Wed, Mar 20, 2019 at 12:37 AM Amit Langote
> wrote:
>> That's because get_relation_constraints() no longer (as of PG 11) includes
>> the partition constraint for SELECT queries.
>
> What commit made that change?
That would
Hi David,
Sorry if this was discussed before, but why does this patch add any new
code to partprune.c? AFAICT, there's no functionality changes to the
pruning code.
Both
+bool
+partkey_is_bool_constant_for_query(RelOptInfo *partrel, int partkeycol)
and
+static bool
On 2019/03/27 15:48, Amit Langote wrote:
> Hi David,
>
> Sorry if this was discussed before, but why does this patch add any new
> code to partprune.c? AFAICT, there's no functionality changes to the
> pruning code.
>
> Both
>
> +bool
> +partkey_is_bool_constant
Tsunakawa-san,
On 2019/03/26 17:21, Tsunakawa, Takayuki wrote:
> From: David Rowley [mailto:david.row...@2ndquadrant.com]
>> On Mon, 25 Mar 2019 at 23:44, Peter Eisentraut
>> wrote:
>>> Perhaps "speeding up planning with partitions" needs to be accepted first?
>>
>> Yeah, I think it likely will
Hi Alvaro,
On 2019/03/22 6:54, Alvaro Herrera wrote:
> Here's v7;
Needs rebasing on top of 940311e4bb3.
0001:
+ Oid objectClass = getObjectClass(thisobj);
I guess you meant to use ObjectClass, not Oid here.
Tested 0002 a bit more and found some problems.
Hi Jesper,
On 2019/03/22 22:01, Jesper Pedersen wrote:
> Hi Alvaro,
>
> On 3/21/19 6:18 PM, Alvaro Herrera wrote:
>> On 2019-Mar-21, Jesper Pedersen wrote:
>>> pgbench -M prepared -f select.sql
>>>
>>> I'm seeing 82.64% spent in GetCachedPlan(). plan_cache_mode is auto.
>>
>> Hmm, I can't
On 2019/03/22 17:17, Amit Langote wrote:
> I'll add this to July fest to avoid forgetting about this.
I'd forgotten to do this, but done today. :)
Thanks,
Amit
Hi,
On 2019/03/23 2:36, Thibaut Madelaine wrote:
> I tested your last patch and if I didn't mix up patches on the end of a
> too long week, I get a problem when querying the sub-sub partition:
>
> test=# explain select * from test2_0_10 where id = 25;
> QUERY PLAN
On 2019/04/04 11:13, David Rowley wrote:
> On Thu, 4 Apr 2019 at 15:01, Amit Langote
> wrote:
>> Sorry, I didn't understand why it wouldn't be OK to pass NoLock to
>> index_open, for example, here:
>>
>> @@ -5191,7 +5191,14 @@ get_actual_variable_range(PlannerI
Hi David,
Thanks for updating the patch.
On 2019/04/04 9:14, David Rowley wrote:
> I also looked over other index_open() calls in the planner and found a
> bunch of places in selfuncs.c that we open an index to grab some
> information then close it again releasing the lock. At this stage
>
On 2019/04/04 4:45, Jesper Pedersen wrote:
> On 4/3/19 1:52 PM, Alvaro Herrera wrote:
>> Pushed, many thanks Amit and Jesper for reviewing.
>>
>
> Thank you for working on this feature.
+1, thank you.
Regards,
Amit
Hi,
On 2019/04/04 13:37, Tsunakawa, Takayuki wrote:
> Hi Peter,
>
> From: Peter Eisentraut [mailto:peter.eisentr...@2ndquadrant.com]
>> I did a bit of performance testing, both a plain pgbench and the
>> suggested test case with 4096 partitions. I can't detect any
>> performance improvements.
On 2019/04/04 16:52, Peter Eisentraut wrote:
> On 2019-04-02 20:54, Erik Rijkers wrote:
>> attached is run_ft.sh which creates a text file: /tmp/pg_head.txt
>> then sets it up as a foreign table, and adds a generated column.
>>
>> Then selects a succesful select, followed by a error-producing
Hi Alvaro,
On 2019/04/03 21:01, Alvaro Herrera wrote:
> On 2019-Apr-03, Kyotaro HORIGUCHI wrote:
>
>> Hello.
>>
>> At Wed, 3 Apr 2019 12:55:06 +0900, Amit Langote
>> wrote in
>>
>>> On 2019/04/03 12:02, Kyotaro HORIGUCHI wrote:
>>>>
On Thu, Apr 4, 2019 at 8:01 PM Peter Eisentraut
wrote:
>
> On 2019-04-04 11:42, Amit Langote wrote:
> > Hmm, I'm afraid we might get bug reports if we go with this. Why is it OK
> > to get null in this case when a user explicitly asked for 'foo'?
>
> The way store
701 - 800 of 2322 matches
Mail list logo
