On 2015-04-25 20:47:04 -0400, Tom Lane wrote:
Since default_with_oids is really only meant as a backwards-compatibility
hack, I don't personally have a problem with restricting it to act only on
plain tables.
FWIW, I think we're getting pretty close to the point, or are there
even, where we
Andres Freund and...@anarazel.de writes:
FWIW, I think we're getting pretty close to the point, or are there
even, where we can remove default_with_oids. So not adding complications
because of it sounds good to me.
Well, pg_dump uses it --- so the argument about not breaking old dump
scripts
Etsuro Fujita fujita.ets...@lab.ntt.co.jp writes:
On 2015/04/16 16:05, Etsuro Fujita wrote:
I agree with you on this point. However, ISTM there is a bug in
handling OIDs on foreign tables; while we now allow for ALTER SET
WITH/WITHOUT OIDS, we still don't allow the default_with_oids parameter
Etsuro,
* Etsuro Fujita (fujita.ets...@lab.ntt.co.jp) wrote:
postgres=# select * from ft1 for update;
ERROR: could not find junk tableoid1 column
I think this is a bug. Attached is a patch fixing this issue.
Pushed, thanks!
Stephen
signature.asc
Description: Digital signature
On 2015/04/23 0:34, Stephen Frost wrote:
* Etsuro Fujita (fujita.ets...@lab.ntt.co.jp) wrote:
postgres=# select * from ft1 for update;
ERROR: could not find junk tableoid1 column
I think this is a bug. Attached is a patch fixing this issue.
Pushed, thanks!
Thank you.
Best regards,
Hello,
At Thu, 16 Apr 2015 14:43:33 -0700, David Fetter da...@fetter.org wrote in
20150416214333.ga...@fetter.org
On Wed, Apr 15, 2015 at 09:35:05AM +0900, Kyotaro HORIGUCHI wrote:
Hi,
Before suppressing the symptom, I doubt the necessity and/or
validity of giving foreign tables an
On Tue, Apr 14, 2015 at 8:35 PM, Kyotaro HORIGUCHI
horiguchi.kyot...@lab.ntt.co.jp wrote:
Before suppressing the symptom, I doubt the necessity and/or
validity of giving foreign tables an ability to be a parent. Is
there any reasonable usage for the ability?
Gee, I don't see why that would be
On 2015/04/16 16:05, Etsuro Fujita wrote:
On 2015/03/23 2:57, Tom Lane wrote:
Etsuro Fujita fujita.ets...@lab.ntt.co.jp writes:
[ fdw-inh-8.patch ]
I've committed this with some substantial rearrangements, notably:
* As I mentioned earlier, I got rid of a few unnecessary restrictions on
On 2015/03/23 2:57, Tom Lane wrote:
Etsuro Fujita fujita.ets...@lab.ntt.co.jp writes:
[ fdw-inh-8.patch ]
I've committed this with some substantial rearrangements, notably:
* As I mentioned earlier, I got rid of a few unnecessary restrictions on
foreign tables so as to avoid introducing
Hello,
At Thu, 16 Apr 2015 12:20:47 +0900, Etsuro Fujita fujita.ets...@lab.ntt.co.jp
wrote in 552f2a8f.2090...@lab.ntt.co.jp
On 2015/04/15 3:52, Alvaro Herrera wrote:
On 4/14/15 5:49 AM, Etsuro Fujita wrote:
postgres=# create foreign table ft1 (c1 int) server myserver options
(table_name
On Wed, Apr 15, 2015 at 09:35:05AM +0900, Kyotaro HORIGUCHI wrote:
Hi,
Before suppressing the symptom, I doubt the necessity and/or
validity of giving foreign tables an ability to be a parent. Is
there any reasonable usage for the ability?
I think we should choose to inhibit foreign
On 2015/04/15 3:52, Alvaro Herrera wrote:
On 4/14/15 5:49 AM, Etsuro Fujita wrote:
postgres=# create foreign table ft1 (c1 int) server myserver options
(table_name 't1');
CREATE FOREIGN TABLE
postgres=# create foreign table ft2 (c1 int) server myserver options
(table_name 't2');
CREATE FOREIGN
On 2015/03/23 2:57, Tom Lane wrote:
Etsuro Fujita fujita.ets...@lab.ntt.co.jp writes:
[ fdw-inh-8.patch ]
I've committed this with some substantial rearrangements, notably:
* I thought that if we were doing this at all, we should go all the way
and allow foreign tables to be both
On 4/14/15 5:49 AM, Etsuro Fujita wrote:
postgres=# create foreign table ft1 (c1 int) server myserver options
(table_name 't1');
CREATE FOREIGN TABLE
postgres=# create foreign table ft2 (c1 int) server myserver options
(table_name 't2');
CREATE FOREIGN TABLE
postgres=# alter foreign table
Hi,
Before suppressing the symptom, I doubt the necessity and/or
validity of giving foreign tables an ability to be a parent. Is
there any reasonable usage for the ability?
I think we should choose to inhibit foreign tables from becoming
a parent rather than leaving it allowed then taking
Jim Nasby wrote:
On 4/14/15 5:49 AM, Etsuro Fujita wrote:
postgres=# create foreign table ft1 (c1 int) server myserver options
(table_name 't1');
CREATE FOREIGN TABLE
postgres=# create foreign table ft2 (c1 int) server myserver options
(table_name 't2');
CREATE FOREIGN TABLE
On Mon, Mar 23, 2015 at 12:09 AM, Robert Haas robertmh...@gmail.com wrote:
On Sun, Mar 22, 2015 at 1:57 PM, Tom Lane t...@sss.pgh.pa.us wrote:
Etsuro Fujita fujita.ets...@lab.ntt.co.jp writes:
[ fdw-inh-8.patch ]
I've committed this with some substantial rearrangements, notably:
I'm
On 2015/03/23 2:57, Tom Lane wrote:
I've committed this with some substantial rearrangements, notably:
Thanks for taking the time to committing the patch!
Thanks for the work, Hanada-san! And thank you everyone for the reviews
and comments, especially Ashutosh, Horiguchi-san and Noah!
* I
Etsuro Fujita fujita.ets...@lab.ntt.co.jp writes:
[ fdw-inh-8.patch ]
I've committed this with some substantial rearrangements, notably:
* I thought that if we were doing this at all, we should go all the way
and allow foreign tables to be both inheritance parents and children.
* As I
On Sun, Mar 22, 2015 at 1:57 PM, Tom Lane t...@sss.pgh.pa.us wrote:
Etsuro Fujita fujita.ets...@lab.ntt.co.jp writes:
[ fdw-inh-8.patch ]
I've committed this with some substantial rearrangements, notably:
I'm really glad this is going in! Thanks to to Shigeru Hanada and
Etsuro Fujita for
Etsuro Fujita fujita.ets...@lab.ntt.co.jp writes:
I noticed that the latter disallows TRUNCATE on inheritance trees that
contain at least one child foreign table. But I think it would be
better to allow it, with the semantics that we quietly ignore the child
foreign tables and apply the
On 2015/01/15 16:35, Etsuro Fujita wrote:
On 2014/12/23 0:36, Tom Lane wrote:
Yeah, we need to do something about the PlanRowMark data structure.
Aside from the pre-existing issue in postgres_fdw, we need to fix it
to support inheritance trees in which more than one rowmark method
is being
On 2014/12/23 0:36, Tom Lane wrote:
Yeah, we need to do something about the PlanRowMark data structure.
Aside from the pre-existing issue in postgres_fdw, we need to fix it
to support inheritance trees in which more than one rowmark method
is being used. That rte.hasForeignChildren thing is a
On 2014/12/23 0:36, Tom Lane wrote:
Yeah, we need to do something about the PlanRowMark data structure.
Aside from the pre-existing issue in postgres_fdw, we need to fix it
to support inheritance trees in which more than one rowmark method
is being used. That rte.hasForeignChildren thing is a
On 2014/12/18 7:04, Tom Lane wrote:
Etsuro Fujita fujita.ets...@lab.ntt.co.jp writes:
Attached are updated patches. Patch fdw-inh-5.patch has been created on
top of patch fdw-chk-5.patch.
I've committed fdw-chk-5.patch with some minor further adjustments;
Have not looked at the other patch
Etsuro Fujita fujita.ets...@lab.ntt.co.jp writes:
I haven't done anything about the issue that postgresGetForeignPlan() is
using get_parse_rowmark(), discussed in eg, [2]. Tom, will you work on
that?
Yeah, we need to do something about the PlanRowMark data structure.
Aside from the
Etsuro Fujita fujita.ets...@lab.ntt.co.jp writes:
Attached are updated patches. Patch fdw-inh-5.patch has been created on
top of patch fdw-chk-5.patch. Patch fdw-chk-5.patch is basically the
same as the previous one fdw-chk-4.patch, but I slightly modified that
one. The changes are the
(2014/12/18 7:04), Tom Lane wrote:
Etsuro Fujita fujita.ets...@lab.ntt.co.jp writes:
Attached are updated patches. Patch fdw-inh-5.patch has been created on
top of patch fdw-chk-5.patch. Patch fdw-chk-5.patch is basically the
same as the previous one fdw-chk-4.patch, but I slightly modified
On Thu, Dec 11, 2014 at 2:54 PM, Ashutosh Bapat
ashutosh.ba...@enterprisedb.com wrote:
On Thu, Dec 11, 2014 at 8:39 AM, Etsuro Fujita fujita.ets...@lab.ntt.co.jp
wrote:
Hi Ashutosh,
Thanks for the review!
(2014/12/10 14:47), Ashutosh Bapat wrote:
We haven't heard anything from
(2014/12/11 14:54), Ashutosh Bapat wrote:
I marked this as ready for committer.
Many thanks!
Best regards,
Etsuro Fujita
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
Hi Ashutosh,
Thanks for the review!
(2014/12/10 14:47), Ashutosh Bapat wrote:
We haven't heard anything from Horiguchi-san and Hanada-san for almost a
week. So, I am fine marking it as ready for committer. What do you say?
ISTM that both of them are not against us, so let's ask for the
I marked this as ready for committer.
On Thu, Dec 11, 2014 at 8:39 AM, Etsuro Fujita fujita.ets...@lab.ntt.co.jp
wrote:
Hi Ashutosh,
Thanks for the review!
(2014/12/10 14:47), Ashutosh Bapat wrote:
We haven't heard anything from Horiguchi-san and Hanada-san for almost a
week. So, I am
Hi Ashutosh,
Thanks for the review!
(2014/11/28 18:14), Ashutosh Bapat wrote:
On Thu, Nov 27, 2014 at 3:52 PM, Etsuro Fujita
fujita.ets...@lab.ntt.co.jp mailto:fujita.ets...@lab.ntt.co.jp wrote:
(2014/11/17 17:55), Ashutosh Bapat wrote:
Here are my review comments for patch
We haven't heard anything from Horiguchi-san and Hanada-san for almost a
week. So, I am fine marking it as ready for committer. What do you say?
On Wed, Dec 10, 2014 at 8:48 AM, Etsuro Fujita fujita.ets...@lab.ntt.co.jp
wrote:
Hi Ashutosh,
Thanks for the review!
(2014/11/28 18:14),
(2014/12/08 15:17), Ashutosh Bapat wrote:
On Sat, Dec 6, 2014 at 9:21 PM, Noah Misch n...@leadboat.com
mailto:n...@leadboat.com wrote:
Does this inheritance patch add any
atomicity
problem that goes away when one breaks up the inheritance hierarchy and
UPDATEs each table
(2014/12/07 2:02), David Fetter wrote:
On Thu, Dec 04, 2014 at 12:35:54PM +0900, Etsuro Fujita wrote:
But I think
there would be another idea. An example will be shown below. We show the
update commands below the ModifyTable node, not above the corresponding
ForeignScan nodes, so maybe less
On Sat, Dec 6, 2014 at 9:21 PM, Noah Misch n...@leadboat.com wrote:
On Thu, Dec 04, 2014 at 10:00:14AM +0530, Ashutosh Bapat wrote:
On Thu, Dec 4, 2014 at 9:05 AM, Etsuro Fujita
fujita.ets...@lab.ntt.co.jp wrote:
(2014/12/03 19:35), Ashutosh Bapat wrote:
On Tue, Dec 2, 2014 at 8:29 AM,
On Thu, Dec 04, 2014 at 10:00:14AM +0530, Ashutosh Bapat wrote:
On Thu, Dec 4, 2014 at 9:05 AM, Etsuro Fujita fujita.ets...@lab.ntt.co.jp
wrote:
(2014/12/03 19:35), Ashutosh Bapat wrote:
On Tue, Dec 2, 2014 at 8:29 AM, Etsuro Fujita
fujita.ets...@lab.ntt.co.jp
On Thu, Dec 04, 2014 at 12:35:54PM +0900, Etsuro Fujita wrote:
(2014/12/03 19:35), Ashutosh Bapat wrote:
On Tue, Dec 2, 2014 at 8:29 AM, Etsuro Fujita
fujita.ets...@lab.ntt.co.jp mailto:fujita.ets...@lab.ntt.co.jp wrote:
This is not exactly extension of non-inheritance case. non-inheritance
On Tue, Dec 2, 2014 at 8:29 AM, Etsuro Fujita fujita.ets...@lab.ntt.co.jp
wrote:
(2014/11/28 18:14), Ashutosh Bapat wrote:
On Thu, Nov 27, 2014 at 3:52 PM, Etsuro Fujita
fujita.ets...@lab.ntt.co.jp mailto:fujita.ets...@lab.ntt.co.jp wrote:
Apart from the above, I noticed that the patch
On Wed, Dec 3, 2014 at 4:05 PM, Ashutosh Bapat
ashutosh.ba...@enterprisedb.com wrote:
On Tue, Dec 2, 2014 at 8:29 AM, Etsuro Fujita fujita.ets...@lab.ntt.co.jp
wrote:
(2014/11/28 18:14), Ashutosh Bapat wrote:
On Thu, Nov 27, 2014 at 3:52 PM, Etsuro Fujita
fujita.ets...@lab.ntt.co.jp
On Thu, Dec 4, 2014 at 9:05 AM, Etsuro Fujita fujita.ets...@lab.ntt.co.jp
wrote:
(2014/12/03 19:35), Ashutosh Bapat wrote:
On Tue, Dec 2, 2014 at 8:29 AM, Etsuro Fujita
fujita.ets...@lab.ntt.co.jp mailto:fujita.ets...@lab.ntt.co.jp wrote:
This is not exactly extension of non-inheritance
Sorry, here's the script.
On Thu, Dec 4, 2014 at 10:00 AM, Ashutosh Bapat
ashutosh.ba...@enterprisedb.com wrote:
On Thu, Dec 4, 2014 at 9:05 AM, Etsuro Fujita fujita.ets...@lab.ntt.co.jp
wrote:
(2014/12/03 19:35), Ashutosh Bapat wrote:
On Tue, Dec 2, 2014 at 8:29 AM, Etsuro Fujita
(2014/11/28 18:14), Ashutosh Bapat wrote:
On Thu, Nov 27, 2014 at 3:52 PM, Etsuro Fujita
fujita.ets...@lab.ntt.co.jp mailto:fujita.ets...@lab.ntt.co.jp wrote:
Apart from the above, I noticed that the patch doesn't consider to
call ExplainForeignModify during EXPLAIN for an inherited
On Thu, Nov 27, 2014 at 3:52 PM, Etsuro Fujita fujita.ets...@lab.ntt.co.jp
wrote:
(2014/11/17 17:55), Ashutosh Bapat wrote:
Here are my review comments for patch fdw-inh-3.patch.
Thanks for the review!
Tests
---
1. It seems like you have copied from testcase inherit.sql to
(2014/11/17 17:55), Ashutosh Bapat wrote:
Here are my review comments for patch fdw-inh-3.patch.
Thanks for the review!
Tests
---
1. It seems like you have copied from testcase inherit.sql to
postgres_fdw testcase. That's a good thing, but it makes the test quite
long. May be we should
On Mon, Nov 17, 2014 at 1:25 PM, Etsuro Fujita fujita.ets...@lab.ntt.co.jp
wrote:
(2014/11/12 20:04), Ashutosh Bapat wrote:
I reviewed fdw-chk-3 patch. Here are my comments
Thanks for the review!
Tests
---
1. The tests added in file_fdw module look good. We should add tests for
(2014/11/18 18:09), Ashutosh Bapat wrote:
I looked at the patch. It looks good now. Once we have the inh patch
ready, we can mark this item as ready for commiter.
Thanks for the review!
Best regards,
Etsuro Fujita
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make
Hi Fujita-san,
I reviewed fdw-chk-3 patch. Here are my comments
Sanity
1. The patch applies on the latest master using patch but not by git apply
2. it compiles clean
3. Regression run is clean, including the contrib module regressions
Tests
---
1. The tests added in file_fdw module
Hi Fujita-san,
I tried to apply fdw-inh-3.patch on the latest head from master branch. It
failed to apply using both patch and git apply.
patch failed to apply because of rejections in
contrib/file_fdw/output/file_fdw.source and
doc/src/sgml/ref/create_foreign_table.sgml
On Fri, Nov 7, 2014 at
Hi Ashutosh,
Thanks for the review!
(2014/11/13 15:23), Ashutosh Bapat wrote:
I tried to apply fdw-inh-3.patch on the latest head from master branch.
It failed to apply using both patch and git apply.
patch failed to apply because of rejections in
contrib/file_fdw/output/file_fdw.source and
On Thu, Nov 13, 2014 at 12:20 PM, Etsuro Fujita fujita.ets...@lab.ntt.co.jp
wrote:
Hi Ashutosh,
Thanks for the review!
(2014/11/13 15:23), Ashutosh Bapat wrote:
I tried to apply fdw-inh-3.patch on the latest head from master branch.
It failed to apply using both patch and git apply.
Hi Furuya-san,
(2014/11/07 16:54), furu...@pm.nttdata.co.jp wrote:
(2014/08/28 18:00), Etsuro Fujita wrote:
(2014/08/22 11:51), Noah Misch wrote:
Today's ANALYZE VERBOSE messaging for former inheritance parents
(tables with relhassubclass = true but no pg_inherits.inhparent
links) is
(2014/11/07 14:57), Kyotaro HORIGUCHI wrote:
Here are separated patches.
fdw-chk.patch - CHECK constraints on foreign tables
fdw-inh.patch - table inheritance with foreign tables
The latter has been created on top of [1].
[1]
Hello, I don't fully catch up this topic but tried this one.
Here are separated patches.
fdw-chk.patch - CHECK constraints on foreign tables
fdw-inh.patch - table inheritance with foreign tables
The latter has been created on top of [1].
[1]
(2014/08/28 18:00), Etsuro Fujita wrote:
(2014/08/22 11:51), Noah Misch wrote:
Today's ANALYZE VERBOSE messaging for former inheritance parents
(tables with relhassubclass = true but no pg_inherits.inhparent
links) is deceptive, and I welcome a fix to omit the spurious
message. As
(2014/10/21 17:40), Etsuro Fujita wrote:
(2014/10/14 20:00), Etsuro Fujita wrote:
Here are separated patches.
fdw-chk.patch - CHECK constraints on foreign tables
fdw-inh.patch - table inheritance with foreign tables
The latter has been created on top of [1].
[1]
(2014/10/14 20:00), Etsuro Fujita wrote:
Here are separated patches.
fdw-chk.patch - CHECK constraints on foreign tables
fdw-inh.patch - table inheritance with foreign tables
The latter has been created on top of [1].
[1] http://www.postgresql.org/message-id/540da168.3040...@lab.ntt.co.jp
(2014/08/28 18:00), Etsuro Fujita wrote:
(2014/08/22 11:51), Noah Misch wrote:
Today's ANALYZE VERBOSE messaging for former inheritance parents
(tables with
relhassubclass = true but no pg_inherits.inhparent links) is
deceptive, and I
welcome a fix to omit the spurious message. As defects go,
(2014/09/12 16:30), Etsuro Fujita wrote:
(2014/09/11 20:51), Heikki Linnakangas wrote:
On 09/11/2014 02:30 PM, Etsuro Fujita wrote:
So, should I split the patch into the two?
Yeah, please do.
OK, Will do.
Here are separated patches.
fdw-chk.patch - CHECK constraints on foreign tables
(2014/09/11 20:51), Heikki Linnakangas wrote:
On 09/11/2014 02:30 PM, Etsuro Fujita wrote:
So, should I split the patch into the two?
Yeah, please do.
OK, Will do.
Thanks,
Best regards,
Etsuro Fujita
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes
(2014/09/11 4:32), Heikki Linnakangas wrote:
I had a cursory look at this patch and the discussions around this.
Thank you!
ISTM there are actually two new features in this: 1) allow CHECK
constraints on foreign tables, and 2) support inheritance for foreign
tables. How about splitting it
On 09/11/2014 12:22 PM, Etsuro Fujita wrote:
(2014/09/11 4:32), Heikki Linnakangas wrote:
I had a cursory look at this patch and the discussions around this.
Thank you!
ISTM there are actually two new features in this: 1) allow CHECK
constraints on foreign tables, and 2) support inheritance
(2014/09/11 19:46), Heikki Linnakangas wrote:
On 09/11/2014 12:22 PM, Etsuro Fujita wrote:
(2014/09/11 4:32), Heikki Linnakangas wrote:
I had a cursory look at this patch and the discussions around this.
Thank you!
ISTM there are actually two new features in this: 1) allow CHECK
On 09/11/2014 02:30 PM, Etsuro Fujita wrote:
Actually, this patch allows the exact same thing to apply to foreign
tables. My explanation was insufficient about that. Sorry for that.
Great, that's what I thought.
So, should I split the patch into the two?
Yeah, please do.
- Heikki
--
I had a cursory look at this patch and the discussions around this.
ISTM there are actually two new features in this: 1) allow CHECK
constraints on foreign tables, and 2) support inheritance for foreign
tables. How about splitting it into two?
- Heikki
--
Sent via pgsql-hackers mailing
Hello, I have a request with slight significance for the messages.
I'd like to address this by emitting the second message as shown below:
INFO: analyzing public.parent
INFO: parent: scanned 0 of 0 pages, containing 0 live rows and 0 dead
rows; 0 rows in sample, 0 estimated total rows
(2014/08/22 11:51), Noah Misch wrote:
On Wed, Aug 20, 2014 at 08:11:01PM +0900, Etsuro Fujita wrote:
(2014/07/02 11:23), Noah Misch wrote:
Your chosen ANALYZE behavior is fair, but the messaging from a database-wide
ANALYZE VERBOSE needs work:
INFO: analyzing test_foreign_inherit.parent
Hi Fujita-san,
I reviewed the v4 patch, and here are some comments from me.
* After applying this patch, pull_varattnos() should not called in
unnecessary places. For developers who want list of
columns-to-be-processed for some purpose, it would be nice to mention
when they should use
Etsuro Fujita fujita.ets...@lab.ntt.co.jp writes:
[ attr_needed-v4.patch ]
I looked this over, and TBH I'm rather disappointed. The patch adds
150 lines of dubiously-correct code in order to save ... uh, well,
actually it *adds* code, because the places that are supposedly getting
a benefit are
(2014/08/27 3:27), Tom Lane wrote:
Etsuro Fujita fujita.ets...@lab.ntt.co.jp writes:
[ attr_needed-v4.patch ]
I looked this over, and TBH I'm rather disappointed. The patch adds
150 lines of dubiously-correct code in order to save ... uh, well,
Just for my study, could you tell me why you
Etsuro Fujita fujita.ets...@lab.ntt.co.jp writes:
(2014/08/27 3:27), Tom Lane wrote:
I looked this over, and TBH I'm rather disappointed. The patch adds
150 lines of dubiously-correct code in order to save ... uh, well,
Just for my study, could you tell me why you think that the code is
(2014/08/27 11:06), Tom Lane wrote:
Etsuro Fujita fujita.ets...@lab.ntt.co.jp writes:
(2014/08/27 3:27), Tom Lane wrote:
I looked this over, and TBH I'm rather disappointed. The patch adds
150 lines of dubiously-correct code in order to save ... uh, well,
Just for my study, could you tell
(2014/08/22 12:58), Alvaro Herrera wrote:
Noah Misch wrote:
I'm anticipating a bug report along these lines:
I saw poor estimates involving a child foreign table, so I ran ANALYZE
VERBOSE, which reported 'INFO: analyzing public.parent inheritance
tree'. Estimates remained poor, so
(2014/08/21 13:21), Ashutosh Bapat wrote:
On Wed, Aug 20, 2014 at 3:25 PM, Etsuro Fujita
fujita.ets...@lab.ntt.co.jp mailto:fujita.ets...@lab.ntt.co.jp wrote:
Hi Ashutish,
I am sorry that I mistook your name's spelling.
(2014/08/14 22:30), Ashutosh Bapat wrote:
On Thu,
(2014/07/02 11:23), Noah Misch wrote:
On Fri, Jun 20, 2014 at 05:04:06PM +0900, Kyotaro HORIGUCHI wrote:
Attached is the rebased patch of v11 up to the current master.
The rest of these review comments are strictly observations; they're not
requests for you to change the patch, but they may
On Wed, Aug 20, 2014 at 08:11:01PM +0900, Etsuro Fujita wrote:
(2014/07/02 11:23), Noah Misch wrote:
Your chosen ANALYZE behavior is fair, but the messaging from a database-wide
ANALYZE VERBOSE needs work:
INFO: analyzing test_foreign_inherit.parent
INFO: parent: scanned 1 of 1 pages,
Noah Misch wrote:
I'm anticipating a bug report along these lines:
I saw poor estimates involving a child foreign table, so I ran ANALYZE
VERBOSE, which reported 'INFO: analyzing public.parent inheritance
tree'. Estimates remained poor, so I scratched my head for awhile before
On Thu, Aug 21, 2014 at 3:00 PM, Etsuro Fujita fujita.ets...@lab.ntt.co.jp
wrote:
(2014/08/21 13:21), Ashutosh Bapat wrote:
On Wed, Aug 20, 2014 at 3:25 PM, Etsuro Fujita
fujita.ets...@lab.ntt.co.jp mailto:fujita.ets...@lab.ntt.co.jp wrote:
Hi Ashutish,
I am sorry that I mistook
Hi Ashutish,
(2014/08/14 22:30), Ashutosh Bapat wrote:
On Thu, Aug 14, 2014 at 10:05 AM, Etsuro Fujita
fujita.ets...@lab.ntt.co.jp mailto:fujita.ets...@lab.ntt.co.jp wrote:
(2014/08/08 18:51), Etsuro Fujita wrote:
(2014/06/30 22:48), Tom Lane wrote:
I wonder whether it isn't
Hi Noah,
Thank you for the review!
(2014/07/02 11:23), Noah Misch wrote:
On Fri, Jun 20, 2014 at 05:04:06PM +0900, Kyotaro HORIGUCHI wrote:
Attached is the rebased patch of v11 up to the current master.
I've been studying this patch.
SELECT FOR UPDATE on the inheritance parent fails with a
On Wed, Aug 20, 2014 at 3:25 PM, Etsuro Fujita fujita.ets...@lab.ntt.co.jp
wrote:
Hi Ashutish,
(2014/08/14 22:30), Ashutosh Bapat wrote:
On Thu, Aug 14, 2014 at 10:05 AM, Etsuro Fujita
fujita.ets...@lab.ntt.co.jp mailto:fujita.ets...@lab.ntt.co.jp wrote:
(2014/08/08 18:51), Etsuro
Hi,
On Thu, Aug 14, 2014 at 10:05 AM, Etsuro Fujita fujita.ets...@lab.ntt.co.jp
wrote:
(2014/08/08 18:51), Etsuro Fujita wrote:
(2014/06/30 22:48), Tom Lane wrote:
I wonder whether it isn't time to change that. It was coded like that
originally only because calculating the values
(2014/08/08 18:51), Etsuro Fujita wrote:
(2014/06/30 22:48), Tom Lane wrote:
I wonder whether it isn't time to change that. It was coded like that
originally only because calculating the values would've been a waste of
cycles at the time. But this is at least the third place where it'd be
(2014/08/06 20:43), Etsuro Fujita wrote:
(2014/06/30 22:48), Tom Lane wrote:
I wonder whether it isn't time to change that. It was coded like that
originally only because calculating the values would've been a waste of
cycles at the time. But this is at least the third place where it'd be
(2014/07/01 11:10), Etsuro Fujita wrote:
(2014/06/30 22:48), Tom Lane wrote:
Etsuro Fujita fujita.ets...@lab.ntt.co.jp writes:
Done. I think this is because create_foreignscan_plan() makes reference
to attr_needed, which isn't computed for inheritance children.
I wonder whether it isn't
(2014/07/10 18:12), Shigeru Hanada wrote:
2014-06-24 16:30 GMT+09:00 Etsuro Fujita fujita.ets...@lab.ntt.co.jp:
(2014/06/23 18:35), Ashutosh Bapat wrote:
Selecting tableoid on parent causes an error, ERROR: cannot extract
system attribute from virtual tuple. The foreign table has an OID
(2014/07/11 15:50), Etsuro Fujita wrote:
(2014/07/10 18:12), Shigeru Hanada wrote:
IIUC, you mean that tableoid can't be retrieved when a foreign table
is accessed via parent table,
No. What I want to say is that tableoid *can* be retrieved when a
foreign table is accessed via the parent
Hi Fujita-san,
Sorry for leaving this thread for long time.
2014-06-24 16:30 GMT+09:00 Etsuro Fujita fujita.ets...@lab.ntt.co.jp:
(2014/06/23 18:35), Ashutosh Bapat wrote:
Hi,
Selecting tableoid on parent causes an error, ERROR: cannot extract
system attribute from virtual tuple. The
If we are going to change that portion of the code, we may as well go a bit
forward and allow any expressions to be fetched from a foreign server
(obviously, if that server is capable of doing so). It will help, when we
come to aggregate push-down or whole query push-down (whenever that
happens).
On Tue, Jul 1, 2014 at 7:39 AM, Etsuro Fujita fujita.ets...@lab.ntt.co.jp
wrote:
(2014/06/30 20:17), Ashutosh Bapat wrote:
On Mon, Jun 30, 2014 at 4:17 PM, Etsuro Fujita
fujita.ets...@lab.ntt.co.jp mailto:fujita.ets...@lab.ntt.co.jp wrote:
(2014/06/30 17:47), Ashutosh Bapat wrote:
Hello,
Sorry, this was no relation with this patch.
ForeignNext materializes the slot, which would be any of physical
and virtual tuple, when system column was requested. If it was a
virtual one, file_fdw makes this, heap_form_tuple generates the
tuple as DatumTuple. The result is a jumble of
(2014/07/01 15:13), Ashutosh Bapat wrote:
On Tue, Jul 1, 2014 at 7:39 AM, Etsuro Fujita
fujita.ets...@lab.ntt.co.jp mailto:fujita.ets...@lab.ntt.co.jp wrote:
We may want to modify use_physical_tlist(), to return false, in case of
foreign tables. BTW, it does return false for inheritance
On Tue, Jul 1, 2014 at 12:25 PM, Etsuro Fujita fujita.ets...@lab.ntt.co.jp
wrote:
(2014/07/01 15:13), Ashutosh Bapat wrote:
On Tue, Jul 1, 2014 at 7:39 AM, Etsuro Fujita
fujita.ets...@lab.ntt.co.jp mailto:fujita.ets...@lab.ntt.co.jp wrote:
We may want to modify use_physical_tlist(), to
(2014/07/01 16:04), Ashutosh Bapat wrote:
On Tue, Jul 1, 2014 at 12:25 PM, Etsuro Fujita
fujita.ets...@lab.ntt.co.jp mailto:fujita.ets...@lab.ntt.co.jp wrote:
Maybe I'm missing something, but what's the point of using the
tlist, not reltargetlist?
Compliance with other
Hi,
At Tue, 01 Jul 2014 16:30:41 +0900, Etsuro Fujita fujita.ets...@lab.ntt.co.jp
wrote in 53b263a1.3060...@lab.ntt.co.jp
I've got the point.
As I said upthread, I'll work on calculating attr_needed for child
rels, and I hope that that will eliminate your concern.
Inheritance tree is
On Fri, Jun 20, 2014 at 05:04:06PM +0900, Kyotaro HORIGUCHI wrote:
Attached is the rebased patch of v11 up to the current master.
I've been studying this patch.
SELECT FOR UPDATE on the inheritance parent fails with a can't-happen error
condition, even when SELECT FOR UPDATE on the child
I checked that it's reporting the right tableoid now.
BTW, why aren't you using the tlist passed to this function? I guess
create_scan_plan() passes tlist after processing it, so that should be used
rather than rel-reltargetlist.
On Mon, Jun 30, 2014 at 12:22 PM, Etsuro Fujita
(2014/06/30 17:47), Ashutosh Bapat wrote:
I checked that it's reporting the right tableoid now.
Thank you for the check.
BTW, why aren't you using the tlist passed to this function? I guess
create_scan_plan() passes tlist after processing it, so that should be
used rather than
On Mon, Jun 30, 2014 at 4:17 PM, Etsuro Fujita fujita.ets...@lab.ntt.co.jp
wrote:
(2014/06/30 17:47), Ashutosh Bapat wrote:
I checked that it's reporting the right tableoid now.
Thank you for the check.
BTW, why aren't you using the tlist passed to this function? I guess
1 - 100 of 173 matches
Mail list logo