->relkind != RELKIND_PARTITIONED_TABLE &&
+list_length(appinfos) < 2) || list_length(appinfos) < 1)
Instead you may rearrage it as
min_child_rels = (rte->relkind == RELKIND_PARTITIONED_TABLE ? 1 : 2);
if (list_length(appinfos) < min_child_rels)
--
Best Wishes,
Ashutosh Bapa
On Wed, Feb 22, 2017 at 11:11 AM, Amit Langote
wrote:
> On 2017/02/22 13:46, Ashutosh Bapat wrote:
>> Looks good to me. In the attached patch I have added a comment
>> explaining the reason to make partition tables "Auto" dependent upon
>> the corresponding pa
On 2017/02/21 20:17, Ashutosh Bapat wrote:
>>> Are you sure you have attached the right patch?
>>
>> Oops, really fixed this time.
>
> Sorry again, 3rd time's a charm. I copy-paste the hunk below from the
> patch file before I attach it to make sure:
>
Please add this to the upcoming commitfest.
On Wed, Feb 22, 2017 at 7:10 AM, Amit Langote
wrote:
> Ashutosh Bapat pointed out [0] that regression tests are missing for the
> foreign partition DDL commands. Attached patch takes care of that.
>
> Thanks,
> Amit
get into problems. PFA patch which adds
those tests.
--
Best Wishes,
Ashutosh Bapat
EnterpriseDB Corporation
The Postgres Database Company
0003-Always-plan-partitioned-tables-as-inheritance-sets_v2.patch
Description: Binary data
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
On Tue, Feb 21, 2017 at 12:05 PM, Amit Langote
wrote:
> Hi Ashutosh,
>
> Thanks for taking a look at the patch.
>
> On 2017/02/20 21:49, Ashutosh Bapat wrote:
>> Thanks for working on all the follow on work for partitioning feature.
>>
>> May be you should
On Tue, Feb 21, 2017 at 9:57 AM, Amit Langote
wrote:
> On 2017/02/21 12:10, Ashutosh Bapat wrote:
>> I think, that's a limitation till we implement global indexes. But
>> nothing in the current implementation stops us from implementing it.
>> In fact, I remember, a re
> unique indexes on a parent table can't guarantee uniqueness across child
> tables is both a surprise, and obvious once stated.
I think, that's a limitation till we implement global indexes. But
nothing in the current implementation stops us from implementing it.
In fact, I r
blocks like
drop table range_parted cascade;
BTW, I noticed that although we are allowing foreign tables to be
partitions, there are no tests in foreign_data.sql for testing it. If
there would have been we would tests DROP TABLE on a partitioned table
with foreign partitions as well. That file has
On Sun, Feb 19, 2017 at 2:33 PM, Robert Haas wrote:
> On Fri, Feb 17, 2017 at 11:44 AM, Ashutosh Bapat
> wrote:
>> That's true for a partitioned table, but not necessarily for every
>> append relation. Amit's patch is generic for all append relations. If
>> the
On Thu, Feb 16, 2017 at 8:15 PM, Robert Haas wrote:
> On Wed, Feb 15, 2017 at 11:15 PM, Ashutosh Bapat
> wrote:
>> If the user is ready throw 200 workers and if the subplans can use
>> them to speed up the query 200 times (obviously I am exaggerating),
>> why not to use
Forgot to attach the patch. Thanks Rajkumar for notifying me.
On Fri, Feb 17, 2017 at 11:18 AM, Ashutosh Bapat
wrote:
> In the documentation of ALTER TABLE ... ATTACH PARTITION its implicit
> that partition name specified should be the name of the existing table
> being attached. Sa
partition being detached. I think this needs to be
more explicit. PFA patch on those lines.
--
Best Wishes,
Ashutosh Bapat
EnterpriseDB Corporation
The Postgres Database Company
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http
as the number of parallel workers for the children the maximum
> of the value computed in step 1 and the value computed in step 2.
>
> With this approach, a plan with 100 children qualifies for 8 parallel
> workers (unless one of the children individually qualifies for some
> larger num
table? With this patch, IIUC,
> WITH OIDS is allowed only if the parent has the same, but WITHOUT OIDS
> is allowed (but ignored) regardless of the parent setting.
>
> --
> Robert Haas
> EnterpriseDB: http://www.enterprisedb.com
> The Enterprise PostgreSQL Company
>
>
> --
> Sent via
On Mon, Feb 6, 2017 at 11:06 AM, Amit Khandekar wrote:
> Ashutosh Bapat wrote:
>>> We may want to think about a third goal: preventing too many workers
>>> from executing the same plan. As per comment in get_parallel_divisor()
>>> we do not see any benefit if more t
ted?
--
Best Wishes,
Ashutosh Bapat
EnterpriseDB Corporation
The Postgres Database Company
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
we split that functionality
into a separate function: in fact, we don't necessarily explain why
certain code resides in a separate function in the comments. I think,
that particular comment (or for that matter other such comments in the
optimizer) can be removed altogether, since it just write
On Thu, Feb 2, 2017 at 2:41 AM, Robert Haas wrote:
> On Mon, Jan 2, 2017 at 7:32 AM, Ashutosh Bapat
> wrote:
>> PFA the patch (pg_dp_join_v6.patch) with some bugs fixed and rebased
>> on the latest code.
>
> Maybe not surprisingly given how fast things are moving around
On Mon, Feb 6, 2017 at 11:10 AM, Tom Lane wrote:
> Ashutosh Bapat writes:
>> On Mon, Feb 6, 2017 at 10:34 AM, Tom Lane wrote:
>>> I'd vote for not. The general programming style in the backend is to
>>> ignore the fact that makeNode() zeroes the node's stor
On Mon, Feb 6, 2017 at 10:34 AM, Tom Lane wrote:
> Ashutosh Bapat writes:
>> Both build_simple_rel() and build_join_rel() allocate RelOptInfo using
>> makeNode(), which returned a zeroed out memory. The functions then
>> assign values like false, NULL, 0 or NIL which essent
Best Wishes,
Ashutosh Bapat
EnterpriseDB Corporation
The Postgres Database Company
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
Please add this patch to the commitfest so that it's not forgotten.
On Fri, Feb 3, 2017 at 6:10 PM, Ashutosh Bapat
wrote:
> The patch applies cleanly. No regression test fails.
>
> On Thu, Feb 2, 2017 at 6:57 PM, Alexey Bashtanov wrote:
>> Hello hac
22 seconds on master branch, 34 milliseconds
> optimized on my laptop.
Yes, that's a lot of improvement. I can reproduce similar results on my laptop.
--
Best Wishes,
Ashutosh Bapat
EnterpriseDB Corporation
The Postgres Database Company
--
Sent via pgsql-hackers mailing list (pgsql-hackers
Sorry, attached wrong patch. Here's the right one.
On Thu, Feb 2, 2017 at 10:04 AM, Ashutosh Bapat
wrote:
> On Thu, Feb 2, 2017 at 8:11 AM, Higuchi, Daisuke
> wrote:
>> From: Ashutosh Bapat [mailto:ashutosh.ba...@enterprisedb.com]
>>> Per the documentation [1], &
On Thu, Feb 2, 2017 at 8:11 AM, Higuchi, Daisuke
wrote:
> From: Ashutosh Bapat [mailto:ashutosh.ba...@enterprisedb.com]
>> Per the documentation [1], "PQgetResult must be called repeatedly
>> until it returns a null pointer, indicating that the command is
>> done.
Please add this to the next commitfest, so that we don't forget it.
On Wed, Feb 1, 2017 at 3:58 PM, Ashutosh Bapat
wrote:
> On Tue, Jan 31, 2017 at 9:53 AM, Higuchi, Daisuke
> wrote:
>> Hello,
>>
>> This this is my first posting to the mailing list.
>>
>
I would have added a test with the patch, but it seems we don't have
much tests in interfaces/libpq. The bug is pretty trivial and would
have been caught easily had we had any tests.
[1] https://www.postgresql.org/docs/devel/static/libpq-async.html
--
Best Wishes,
Ashutosh Bapat
EnterpriseDB Cor
counting in the later patches, which would otherwise generate ugly
> IPC if done for every time a tuple is allocated. I considered using
> atomic add to count space per tuple, or maintaining per-backend local
> subtotals and periodically summing. Then I realised that switching to
> per-
we might be
overdoing it; a reason why we don't track space usage accurately now. But I
think I will leave it to be judged by someone who is more familiar with the
code and possibly has historical perspective.
--
Best Wishes,
Ashutosh Bapat
EnterpriseDB Corporation
The Postgres Database
Type | Modifiers | FDW Options
> +-+---+-
> id | integer | not null |
> Server: mysql_server
> FDW Options: (dbname 'msql_test_db', table_name 'tickets')
>
> Its a foreign table, referring to table 'tickets' defined
On Mon, Jan 30, 2017 at 5:00 PM, Etsuro Fujita
wrote:
> On 2017/01/27 21:25, Etsuro Fujita wrote:
>>
>> On 2017/01/27 20:04, Ashutosh Bapat wrote:
>>>
>>> I think we should pick up your patch on
>>> 27th December, update the comment per your mail on 5
list not in FROM, so the planner would throw
> away those calls.)
>
> Comments/objections?
>
I think this is good in the given infrastructure. Thanks for working on it.
--
Best Wishes,
Ashutosh Bapat
EnterpriseDB Corporation
The Postgres Database Company
--
Sent via pgsql-hac
ot;transaction" by "x". But here "xact" means "transact", which is fine.
May be we should use 'X' instead of 'x', I don't know. Said that, I am
fine with any other name which conveys what the function does.
[1] https://en.wikipedia.org/w
On Fri, Jan 13, 2017 at 12:30 PM, Etsuro Fujita
wrote:
> On 2017/01/12 18:25, Ashutosh Bapat wrote:
>>
>> On Wed, Jan 11, 2017 at 5:45 PM, Etsuro Fujita
>> wrote:
>
>
>>>>> On 2017/01/05 21:11, Ashutosh Bapat wrote:
>>>>>>
>>>&
= 0 instead and keep the filter
condition intact. This increases the execution time by .2s, which may
be ok. Let me know what you thing of the attached patch.
Also, please add this to the commitfest, so that it isn't forgotten.
--
Best Wishes,
Ashutosh Bapat
EnterpriseDB Corporation
The
t;
>>> Check.
>>
>> Here's an updated patch with doc changes. Aside from that one,
>> I tried to spell "pseudo-type" consistently, and I changed one
>> place where we were calling something a pseudo-type that isn't.
I think, those changes, even
for comments on 0003.
>
> It seems patches for all the issues mentioned in this thread so far,
> except 0003 (I just sent an updated version in another email), have been
> committed. Thanks a lot for your time. I will create new threads for any
> more patches from here on.
>
>
for just that.
>
> The CF app has been updated to ready for committer for the record.
I have listed myself as reviewer for this commitfest entry and I am
yet to review the patch. Can you please wait for the listed reviewers,
esp. when those reviewers are active, for changing the commitfes
On Wed, Jan 25, 2017 at 9:58 AM, Haribabu Kommi
wrote:
>
>
> On Wed, Jan 25, 2017 at 2:50 PM, Ashutosh Bapat
> wrote:
>>
>> On Wed, Jan 25, 2017 at 6:34 AM, Michael Paquier
>> wrote:
>> > On Tue, Jan 24, 2017 at 11:19 PM, Ashutosh Bapat
>> &g
On Wed, Jan 25, 2017 at 6:34 AM, Michael Paquier
wrote:
> On Tue, Jan 24, 2017 at 11:19 PM, Ashutosh Bapat
> wrote:
>> On Mon, Jan 23, 2017 at 1:43 PM, Haribabu Kommi
>> wrote:
>>>
>>>
>>> On Sat, Jan 21, 2017 at 8:01 AM, Tom
arnings.
> Changed to a static array.
Thanks. Probably we should update parse_hba_line() to keep it in sync
with the array. But that may be a separate add-on patch.
Rest of the patch looks good to me.
--
Best Wishes,
Ashutosh Bapat
EnterpriseDB Corporation
The Postgres Database Company
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
On Mon, Jan 23, 2017 at 9:56 PM, Tom Lane wrote:
> I wrote:
>> Ashutosh Bapat writes:
>>> UNKNOWN is not exactly a pseudo-type.
>
>> Well, as I said to Michael just now, I think we should turn it into one
>> now that we're disallowing it in tables, becaus
r "line" columns.
>
Following error message might be misleading,
postgres=# create table t1 (a unknown);
ERROR: column "a" has pseudo-type unknown
UNKNOWN is not exactly a pseudo-type.
postgres=# select typname, typtype from pg_type where typname =
'unknown'
umber of
>> options then, it can lead to that assert.
>>
>> Updated patch attached including reverting of file leak changes.
>
> OK, thanks for the new version. I am marking this version as ready for
> committer.
I do intend to make a pass ASAP.
--
Best Wishes,
Ashutosh B
On Thu, Jan 19, 2017 at 10:38 PM, Robert Haas wrote:
> On Wed, Jan 18, 2017 at 10:26 PM, Ashutosh Bapat
> wrote:
>>> Yes, I think that's broadly the approach Tom was recommending.
>>
>> I don't have problem with that approach, but the latest patch has
>&g
r to ParamPathInfo, which contains
> parameterization-specific information, GroupPathInfo would conain the
> grouping-specific information: target, row count, width, maybe path lists too.
>
I didn't think about this option. Still not very clean, but may be acceptable.
--
Best Wishes,
Ashu
at DatumGetVarBitP() and DatumGetByteaP(), that
will get you corresponding structure pointers from a Datum. Then check
src/backend/utils/adt/varbit.c and bytea_* functions from
src/backend/utils/adt/varlena.c to understand how those structures are
used.
--
Best Wishes,
Ashutosh Bapat
Enterp
convert
this into an elog() or another error that hba parser throws.
+Assert(noptions <= MAX_OPTIONS);
--
Best Wishes,
Ashutosh Bapat
EnterpriseDB Corporation
The Postgres Database Company
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
the latest patch has
following problems.
1. We are copying chunks of path creation logic, instead of reusing
corresponding functions.
2. There are many cases where the new function would return no local
path and hence postgres_fdw doesn't push down the join [1]. This will
be performance regressio
On Thu, Jan 19, 2017 at 12:02 AM, Robert Haas wrote:
> On Tue, Jan 17, 2017 at 11:33 PM, Ashutosh Bapat
> wrote:
>> I don't think aggcombinefn isn't there because we couldn't write it
>> for array_agg() or string_agg(). I guess, it won't be efficient to
&g
bms_free(required_outer);
return NULL;
}
Am I right?
The earlier version of this function GetExistingLocalJoinPath() used
to return a local path in those cases and hence postgres_fdw was able
to push down corresponding queries. So, we are introducing a
performan
On Wed, Jan 18, 2017 at 10:55 AM, Michael Paquier
wrote:
> On Sun, Jan 8, 2017 at 10:55 AM, Tom Lane wrote:
>> Ashutosh Bapat writes:
>>> On Tue, Jan 3, 2017 at 5:57 PM, Rahila Syed wrote:
>>>> Are you suggesting extending the patch to include coercing fro
On Tue, Jan 17, 2017 at 10:07 PM, Antonin Houska wrote:
> Ashutosh Bapat wrote:
>> [... snip ]]
>>
>> This all works well, as long as the aggregate is "summing" something
>> across rows. The method doesn't work when aggregation is say
>> "m
On Mon, Jan 16, 2017 at 9:49 AM, Amit Khandekar wrote:
> Thanks Ashutosh for the feedback.
>
> On 6 January 2017 at 17:04, Ashutosh Bapat
> wrote:
>> On Fri, Dec 23, 2016 at 10:51 AM, Amit Khandekar
>> wrote:
>>> Currently an Append plan node does not exe
On Fri, Jan 13, 2017 at 10:12 PM, Antonin Houska wrote:
> Ashutosh Bapat wrote:
>> On Mon, Jan 9, 2017 at 11:26 PM, Antonin Houska wrote:
>> > Attached is a draft patch that lets partial aggregation happen at base
>> > relation level. If the relations contain relati
On Thu, Jan 12, 2017 at 6:39 PM, Tom Lane wrote:
> Ashutosh Bapat writes:
>> The member root in foreign_glob_cxt isn't used anywhere by
>> postgres_fdw code. Without that member the code compiles and
>> regression passes. The member was added by d0d75c40. I looked at
t the big picture. May be you want to share
design (or point out the parts of this design that will help) for
solving smaller problem and tone down the patch for the same.
--
Best Wishes,
Ashutosh Bapat
EnterpriseDB Corporation
The Postgres Database Company
--
Sent via pgsql-hackers mailing
nce it was introduced. Should we drop that member?
PFA the patch to remove that member. If we decide to drop that member,
we can drop root argument to is_foreign_expr() and clean up some more
code. I volunteer to do that, if we agree.
--
Best Wishes,
Ashutosh Bapat
EnterpriseDB Corporation
The Postgre
On Wed, Jan 11, 2017 at 5:45 PM, Etsuro Fujita
wrote:
> On 2017/01/05 21:38, Ashutosh Bapat wrote:
>>
>> On Thu, Jan 5, 2017 at 5:51 PM, Etsuro Fujita
>> wrote:
>>>
>>> On 2017/01/05 21:11, Ashutosh Bapat wrote:
>
>
>>>>> On 2017/01
ld we include "JOIN" in the string returned by this fuction? The
two places where this function is called, append "JOIN" to the string
returned by this function. Although, even without that change, the
patch looks good.
--
Best Wishes,
Ashutosh Bapat
EnterpriseDB Corporation
The
tion level makes no
+ * sense. XXX Is there simpler way to find out? (We're not interested in
+ * RELOPT_OTHER_MEMBER_REL, so simple_rel_array_size does not help.)
+ */
+ for (i = 1; i < root->simple_rel_array_size; i++)
+ {
+ RelOptInfo *rel;
+
+ rel = find_base_rel(root, i);
+ if (rel->reloptkind == RELOPT_BASEREL)
+ {
+ nbaserels++;
+ /*
+ * We only want to know whether the number of relations is greater
+ * than one.
+ */
+ if (nbaserels > 1)
+ break;
+ }
+ }
You might want to check bms_membership(root->all_baserels), instead of
this loop.
--
Best Wishes,
Ashutosh Bapat
EnterpriseDB Corporation
The Postgres Database Company
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
On Wed, Jan 11, 2017 at 3:30 PM, Etsuro Fujita
wrote:
> On 2017/01/11 17:51, Ashutosh Bapat wrote:
>>
>> On Wed, Jan 11, 2017 at 1:15 PM, Etsuro Fujita
>> wrote:
>>>
>>> On 2017/01/11 13:40, Ashutosh Bapat wrote:
>>>>
>>>> Creat
On Wed, Jan 11, 2017 at 1:15 PM, Etsuro Fujita
wrote:
> On 2017/01/11 13:40, Ashutosh Bapat wrote:
>>
>> CreateLocalJoinPath tries to construct a nestloop path for the given
>> join relation because it wants to avoid merge/hash join paths which
>> require expensive setu
condition or the whole block. But I don't see any reason not to
replicate the same conditions in pg_restore.c
--
Best Wishes,
Ashutosh Bapat
EnterpriseDB Corporation
The Postgres Database Company
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
On Fri, Jan 6, 2017 at 6:31 PM, Etsuro Fujita
wrote:
> On 2017/01/05 12:10, Etsuro Fujita wrote:
>>
>> On 2016/12/28 17:34, Ashutosh Bapat wrote:
>>>
>>> Hmm. If I understand the patch correctly, it does not return any path
>>> when merge join is allow
anning. Sorry
for the trouble.
Another concern here is that we are copying pieces of logic in
add_paths_to_joinrel() without arranging it as neatly as in that
function.
--
Best Wishes,
Ashutosh Bapat
EnterpriseDB Corporation
The Postgres Database Company
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
ll_pathkeys)
+{
+extra->mergeclauses = cur_mergeclauses;
+extra->merge_pathkeys = merge_pathkeys;
+extra->merge_outerkeys = outerkeys;
+extra->merge_innerkeys = innerkeys;
+}
--
Best Wishes,
Ashutosh Bapat
EnterpriseDB Corpor
Marking this as ready for committer.
On Wed, Jan 4, 2017 at 12:16 PM, Michael Paquier
wrote:
> On Wed, Jan 4, 2017 at 1:23 PM, Ashutosh Bapat
> wrote:
>> I don't have anything more to review in this patch. I will leave that
>> commitfest entry in "needs review&
On Thu, Jan 5, 2017 at 2:49 PM, Etsuro Fujita
wrote:
> On 2017/01/03 15:57, Ashutosh Bapat wrote:
>>
>> The patch looks good to me, but I feel there are too many testscases.
>> Now that we have changed the approach to invalidate caches in all
>> cases, should we just
hen divides
by parallel_divisor. This might work if all the subpaths are partial paths. But
for the subpaths which are not partial, a single worker will incur the whole
cost of that subpath. Hence just dividing all the total cost doesn't seem the
right thing to do. We should apply different logic
On Thu, Jan 5, 2017 at 5:51 PM, Etsuro Fujita
wrote:
> On 2017/01/05 21:11, Ashutosh Bapat wrote:
>>
>> On Thu, Jan 5, 2017 at 5:14 PM, Etsuro Fujita
>> wrote:
>>>
>>> On 2017/01/03 17:28, Ashutosh Bapat wrote:
>>>>
>>>> In build_sub
On Thu, Jan 5, 2017 at 5:14 PM, Etsuro Fujita
wrote:
> On 2017/01/03 17:28, Ashutosh Bapat wrote:
>
> I wrote:
>>>
>>> I updated the patch a bit further: simplified the function name
>>> (s/build_subquery_rel_tlists/build_subquery_tlists/), and revised
>>
On Wed, Jan 4, 2017 at 8:24 PM, Stephen Frost wrote:
> Ashutosh,
>
> I realize you were replying to yourself, but you probably didn't need to
> include the entire thread below or to top-post.
Sorry, that was unintentional.
>
> * Ashutosh Bapat (ashutosh.ba...@enterp
ply). Searching for an existing path just
requires a search in one relation's pathlist. The path should be
there. Why do we want to spend extra resources in creating a new path
when an old one exists and searching it is more efficient.
--
Best Wishes,
Ashutosh Bapat
EnterpriseDB Corporat
On Thu, Jan 5, 2017 at 8:20 AM, Etsuro Fujita
wrote:
> On 2016/12/27 16:41, Etsuro Fujita wrote:
>>
>> On 2016/12/22 1:04, Ashutosh Bapat wrote:
>>>
>>> 2. We should try to look for other not-so-cheap paths if the cheapest
>>> one
On Thu, Jan 5, 2017 at 9:40 AM, Ashutosh Bapat
wrote:
>>
>>
>>> Hmm. If I understand the patch correctly, it does not return any path
>>> when merge join is allowed and there are merge clauses but no hash
>>> clauses. In this case we will not creat
. spends CPU cycles in costing the path as
well as creating it. Searching for an existing path requires a search
in only one relation's pathlist. The path should be there so we don't
need to construct a new one.
--
Best Wishes,
Ashutosh Bapat
EnterpriseDB Corporation
The Postgres Databas
if it gets any longer
> it'd be appropriate to do that.
Ok.
>
> Pushed with those corrections and some further fooling with the test case.
>
Thanks.
--
Best Wishes,
Ashutosh Bapat
EnterpriseDB Corporation
The Postgres Database Company
--
Sent via pgsql-hackers mailing list
t has examples.
On Thu, Dec 29, 2016 at 10:26 AM, Ashutosh Bapat
wrote:
> On Wed, Dec 28, 2016 at 10:55 PM, Stephen Frost wrote:
>> Tom,
>>
>> * Tom Lane (t...@sss.pgh.pa.us) wrote:
>>> Stephen Frost writes:
>>> > * Tom Lane (t...@sss.pgh.pa.us) wrote:
On Tue, Jan 3, 2017 at 10:09 PM, Robert Haas wrote:
> On Tue, Jan 3, 2017 at 12:06 AM, Ashutosh Bapat
> wrote:
>> Instead of changing get_object_address_unqualified(),
>> get_object_address_unqualified() and pg_get_object_address(), should
>> we just stick get_databa
reate user current_user;
^
postgres=# create database current_database;
CREATE DATABASE
We will need to make CURRENT_DATABASE a reserved keyword. But I like
this idea more than COMMENT ON CURRENT DATABASE.
--
Best Wishes,
Ashutosh Bapat
EnterpriseDB Corporation
The Postgres D
On Tue, Jan 3, 2017 at 6:40 PM, Fabrízio de Royes Mello
wrote:
> Hi Ashutosh,
>
> First of all thanks for your review.
>
>
> On Tue, Jan 3, 2017 at 3:06 AM, Ashutosh Bapat
> wrote:
>>
>> The patch has white space error
>> git apply /mnt/hgfs/tmp/comment_on
d just tackle the
view case in this patch. I would like everything being done in one
patch, rather than this piece-meal approach. But delaying fix for
views because it takes longer to work on other pieces may not be good
either.
--
Best Wishes,
Ashutosh Bapat
EnterpriseDB Corporation
The Postgre
On Tue, Jan 3, 2017 at 5:38 PM, Michael Paquier
wrote:
> On Tue, Jan 3, 2017 at 8:41 PM, Ashutosh Bapat
> wrote:
>> Are you talking about
>> /*
>> * Now we can mark ourselves as out of the commit critical section: a
>> * checkpoint starting after thi
On Tue, Jan 3, 2017 at 2:50 PM, Michael Paquier
wrote:
> On Tue, Jan 3, 2017 at 3:32 PM, Ashutosh Bapat
> wrote:
>> I am wondering what happens if a 2PC file gets created, at the time of
>> checkpoint we flush the pg_twophase directory, then the file gets
>> removed.
t, why do we want to
build it again?
In build_tlist_to_deparse(), if fpinfo->tlist for the given relation is set, we
should just return it rather than constructing it again.
--
Best Wishes,
Ashutosh Bapat
EnterpriseDB Corporation
The Postgres Database Company
--
Sent via pgsql-hackers mail
there are too many testscases.
Now that we have changed the approach to invalidate caches in all
cases, should we just include cases for SELECT or UPDATE or INSERT or
DELETE instead of each statement?
--
Best Wishes,
Ashutosh Bapat
EnterpriseDB Corporation
The Postgres Database Compa
On Sat, Dec 31, 2016 at 5:53 AM, Michael Paquier
wrote:
> On Fri, Dec 30, 2016 at 10:59 PM, Ashutosh Bapat
> wrote:
>>>
>>> Well, flushing the meta-data of pg_twophase is really going to be far
>>> cheaper than the many pages done until CheckpointTwoPhase is reac
40:2: note: each undeclared identifier is reported only
once for each function it appears in
createplan.c: In function ‘create_plan_recurse’:
createplan.c:445:13: error: expected expression before ‘AggPath’
Is the attached patch as per your suggestion?
--
Best Wishes,
Ashutosh Bapat
Enterpr
extra cycles in finding database
id which is ready available as MyDatabaseId, but the code will be
cleaner. Another possibility is to use objnames to store the database
name and objargs to store the database id. That means we overload
objargs, which doesn't looks good either.
--
Best Wishes,
Ash
nc(), but it can't accomodate Assert with _type_. Will
calling this function as checkAndCastNode() help?
--
Best Wishes,
Ashutosh Bapat
EnterpriseDB Corporation
The Postgres Database Company
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
reduce the backpatch impact I would just do the fsync
> if (serialized_xact > 0 || RecoveryInProgress()) and call it a day.
Sounds ok to me. I will leave it to the committer to decide further.
--
Best Wishes,
Ashutosh Bapat
EnterpriseDB Corporation
The Postgres Database Company
--
S
On Fri, Dec 30, 2016 at 11:22 AM, Michael Paquier
wrote:
> On Thu, Dec 29, 2016 at 6:41 PM, Ashutosh Bapat
> wrote:
>> I agree with this.
>> If no prepared transactions were required to be fsynced
>> CheckPointTwoPhase(), do we want to still fsync the directory?
>>
On Thu, Dec 29, 2016 at 8:18 PM, Tom Lane wrote:
> Ashutosh Bapat writes:
>> The way this patch has been written, it doesn't allow creating tables
>> with unknown type columns, which was allowed earlier.
>
> Yes, that's an intentional change; creating such tab
gt; Thank you,
> Rahila Syed
>
>
>
>
> --
> Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
> To make changes to your subscription:
> http://www.postgresql.org/mailpref/pgsql-hackers
>
--
Best Wishes,
Ashutosh Bapat
EnterpriseDB Corporation
The Postgres Database Company
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
relevant
here.
>
> I am adding that as well to the next CF for consideration.
>
> Thoughts?
> --
> Michael
>
>
> --
> Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
> To make changes to your subscription:
> http://www.postgresql.org/mailpref/pgsql
n analyze select * from pg_class c, pg_type t,
pg_inherits i where c.reltype = t.oid and i.inhparent = c.oid;
QUERY PLAN
[ ... ] clipped plan
Planning time: 0.592 ms
Execution time: 2.294 ms
(13 rows)
regression=# \timing
Timing is on.
regression=# explain select * from pg_class c, pg_type t, pg_inherits
i where c.reltype = t.oid and i.inhparent = c.oid;
[...] clipped plan
Time: 1.831 ms
The planning time has almost doubled, but what \timing reported has
only grown by approximately 50%.
--
Best Wishes,
Ashutosh Bapat
EnterpriseDB Corporation
The Postgres Database Company
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
nly would like that, but advanced users who try to control
optimizer might find it helpful. In that case, total planning time
becomes a "summary". In this case "TIMING" would control reporting
granular planning time and SUMMARY would control reporting overall
printing time. I don'
The question there is why we didn't do it to start with?
OR why did we have summary controlling execution time report. Probably
the author thought that at some point in future we might separate
those two. So, I have left summary there. I don't have problem
removing it.
--
Best Wishes,
As
401 - 500 of 973 matches
Mail list logo
