Andres Freund 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 would apply to an
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
Etsuro Fujita 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
>> for foreign table
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,
Etsuro
Hello,
At Thu, 16 Apr 2015 14:43:33 -0700, David Fetter 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 ability t
On Tue, Apr 14, 2015 at 8:35 PM, Kyotaro HORIGUCHI
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 unreasonable or invalid
--
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 signatur
On 2015/04/16 16:05, Etsuro Fujita wrote:
> On 2015/03/23 2:57, Tom Lane wrote:
>> Etsuro Fujita 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
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/03/23 2:57, Tom Lane wrote:
> Etsuro Fujita 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 warts into inheritance
Hello,
At Thu, 16 Apr 2015 12:20:47 +0900, Etsuro Fujita
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 't1');
> >>> C
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 T
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 measure
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 TAB
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 t
On 2015/03/23 2:57, Tom Lane wrote:
> Etsuro Fujita 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 chil
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 f
On Mon, Mar 23, 2015 at 12:09 AM, Robert Haas wrote:
> On Sun, Mar 22, 2015 at 1:57 PM, Tom Lane wrote:
> > Etsuro Fujita 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 Hanad
On Sun, Mar 22, 2015 at 1:57 PM, Tom Lane wrote:
> Etsuro Fujita 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 working on this, to you (Tom) for putting in
Etsuro Fujita 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 mentioned earlier, I got rid of a f
Etsuro Fujita 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 operation to the child pla
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
On Thu, Jan 15, 2015 at 4:35 PM, Etsuro Fujita
wrote:
> As I said before, that seems to me like a good idea. So I'll update the
> patch based on that if you're okey with it. Or you've found any problem
> concerning the above idea?
>
Patch moved to CF 2015-02 with same status, "Ready for commit
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 i
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 i
Etsuro Fujita 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 pre-existing issue in postgres_fdw,
On 2014/12/18 7:04, Tom Lane wrote:
> Etsuro Fujita 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 yet.
I updated the
(2014/12/18 7:04), Tom Lane wrote:
> Etsuro Fujita 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 cha
Etsuro Fujita 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 following.
> * added to f
On Thu, Dec 11, 2014 at 2:54 PM, Ashutosh Bapat
wrote:
> On Thu, Dec 11, 2014 at 8:39 AM, Etsuro Fujita
> 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
>>> wee
(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
I marked this as ready for committer.
On Thu, Dec 11, 2014 at 8:39 AM, Etsuro Fujita
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 fine marking it as "
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
com
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
wrote:
> Hi Ashutosh,
>
> Thanks for the review!
>
> (2014/11/28 18:14), Ashutosh Bapat wrote:
>
>> O
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
mailto: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.
Tests
(2014/12/08 15:17), Ashutosh Bapat wrote:
On Sat, Dec 6, 2014 at 9:21 PM, Noah Misch 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 separately? If not, this
On Sat, Dec 6, 2014 at 9:21 PM, Noah Misch 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, Etsu
(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 co
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
> >mailto:fujita.ets...@lab.ntt.co.jp>> wrote:
>
> >This is not exactly extension of non-inheritance case. non-inheritance
> >case doesn't sho
On Thu, Dec 04, 2014 at 10:00:14AM +0530, Ashutosh Bapat wrote:
> On Thu, Dec 4, 2014 at 9:05 AM, Etsuro Fujita
> wrote:
> > (2014/12/03 19:35), Ashutosh Bapat wrote:
> >> On Tue, Dec 2, 2014 at 8:29 AM, Etsuro Fujita
> >> mailto:fujita.ets...@lab.ntt.co.jp>> wrote:
> > IIUC, even the transa
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 > wrote:
>
>> (2014/12/03 19:35), Ashutosh Bapat wrote:
>>
>>> On Tue, Dec 2, 2014 at 8:29 AM, Etsuro Fujita
>>> mailto:fujita.e
On Thu, Dec 4, 2014 at 9:05 AM, Etsuro Fujita
wrote:
> (2014/12/03 19:35), Ashutosh Bapat wrote:
>
>> On Tue, Dec 2, 2014 at 8:29 AM, Etsuro Fujita
>> mailto:fujita.ets...@lab.ntt.co.jp>> wrote:
>>
>
> This is not exactly extension of non-inheritance case. non-inheritance
>> case doesn't show tw
(2014/12/03 19:35), Ashutosh Bapat wrote:
On Tue, Dec 2, 2014 at 8:29 AM, Etsuro Fujita
mailto:fujita.ets...@lab.ntt.co.jp>> wrote:
This is not exactly extension of non-inheritance case. non-inheritance
case doesn't show two remote SQLs under the same plan node. May be you
can rename the label
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 > wrote:
>
>> (2014/11/28 18:14), Ashutosh Bapat wrote:
>>
>>> On Thu, Nov 27, 2014 at 3:52 PM, Etsuro Fujita
>>> mailto:fujita.ets...@lab.ntt.co.jp>>
>>> w
On Tue, Dec 2, 2014 at 8:29 AM, Etsuro Fujita
wrote:
> (2014/11/28 18:14), Ashutosh Bapat wrote:
>
>> On Thu, Nov 27, 2014 at 3:52 PM, Etsuro Fujita
>> mailto:fujita.ets...@lab.ntt.co.jp>> wrote:
>> Apart from the above, I noticed that the patch doesn't consider to
>> call ExplainForeignM
(2014/11/28 18:14), Ashutosh Bapat wrote:
On Thu, Nov 27, 2014 at 3:52 PM, Etsuro Fujita
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
UPDATE/DELETE, as shown bel
On Thu, Nov 27, 2014 at 3:52 PM, Etsuro Fujita
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
>> postgres_fdw testca
(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 ha
(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
On Mon, Nov 17, 2014 at 1:25 PM, Etsuro Fujita
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
>> CREATE TABLE w
Hi Fujita-san,
Here are my review comments for patch fdw-inh-3.patch.
Sanity
1. The patch applies cleanly
2. It compiles cleanly.
3. The server regression tests and tests in contrib modules pass.
Tests
---
1. It seems like you have copied from testcase inherit.sql to postgres_fdw
tes
(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
CREATE TABLE with CHECK CONSTRAINT also.
Agreed. I added the tests, and also changed the
On Thu, Nov 13, 2014 at 12:20 PM, Etsuro Fujita 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.
>>
>> "patch" failed to
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
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 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
(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]
http://www.postgresql.org/message-id/540da168.3040...@lab.ntt.co
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
l
> (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
> >> mes
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]
> >> http://www
(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] http://www.postgresql.org/
(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, t
(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
fd
(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 to
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
--
Se
(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
constraints
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 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 int
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 lis
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
(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"
INF
(2014/08/27 11:06), Tom Lane wrote:
> Etsuro Fujita 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
Etsuro Fujita 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
> "dubiously-correct"?
It
(2014/08/27 3:27), Tom Lane wrote:
> Etsuro Fujita 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 think that the code is
Etsuro Fujita 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 changed like this:
*** 79
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 pull_varat
(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,
On Thu, Aug 21, 2014 at 3:00 PM, Etsuro Fujita
wrote:
> (2014/08/21 13:21), Ashutosh Bapat wrote:
>
>> On Wed, Aug 20, 2014 at 3:25 PM, Etsuro Fujita
>> mailto:fujita.ets...@lab.ntt.co.jp>> wrote:
>>
>
> Hi Ashutish,
>>
>
> I am sorry that I mistook your name's spelling.
>
> (2014/08/14
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 befo
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 o
(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 d
(2014/08/21 13:21), Ashutosh Bapat wrote:
On Wed, Aug 20, 2014 at 3:25 PM, Etsuro Fujita
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, Aug 14, 2014 at 10:05 AM, Ets
On Wed, Aug 20, 2014 at 3:25 PM, Etsuro Fujita
wrote:
> Hi Ashutish,
>
>
> (2014/08/14 22:30), Ashutosh Bapat wrote:
>
>> On Thu, Aug 14, 2014 at 10:05 AM, Etsuro Fujita
>> mailto:fujita.ets...@lab.ntt.co.jp>> wrote:
>>
>> (2014/08/08 18:51), Etsuro Fujita wrote:
>> >>> (2014/06/30 22:48
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
Hi Ashutish,
(2014/08/14 22:30), Ashutosh Bapat wrote:
On Thu, Aug 14, 2014 at 10:05 AM, Etsuro Fujita
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 time to change that.
Hi,
On Thu, Aug 14, 2014 at 10:05 AM, Etsuro Fujita 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 would've been a wa
(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 wh
(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
(2014/07/01 11:10), Etsuro Fujita wrote:
> (2014/06/30 22:48), Tom Lane wrote:
>> Etsuro Fujita 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 time to change tha
(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 ta
(2014/07/10 18:12), Shigeru Hanada wrote:
2014-06-24 16:30 GMT+09:00 Etsuro Fujita :
(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 which
can be reported as tabl
Hi Fujita-san,
Sorry for leaving this thread for long time.
2014-06-24 16:30 GMT+09:00 Etsuro Fujita :
> (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 foreign table has an O
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 foreig
Hi,
At Tue, 01 Jul 2014 16:30:41 +0900, Etsuro Fujita
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 expanded far after where a
(2014/07/01 16:04), Ashutosh Bapat wrote:
On Tue, Jul 1, 2014 at 12:25 PM, Etsuro Fujita
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 create_*scan_plan() functions. The tlis
On Tue, Jul 1, 2014 at 12:25 PM, Etsuro Fujita
wrote:
> (2014/07/01 15:13), Ashutosh Bapat wrote:
>
>> On Tue, Jul 1, 2014 at 7:39 AM, Etsuro Fujita
>> mailto:fujita.ets...@lab.ntt.co.jp>> wrote:
>>
>
> We may want to modify use_physical_tlist(), to return false, in case of
>> foreign tables. BT
(2014/07/01 15:13), Ashutosh Bapat wrote:
On Tue, Jul 1, 2014 at 7:39 AM, Etsuro Fujita
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 trees.
Yeah, but please consid
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 vir
On Tue, Jul 1, 2014 at 7:39 AM, Etsuro Fujita
wrote:
> (2014/06/30 20:17), Ashutosh Bapat wrote:
>
>> On Mon, Jun 30, 2014 at 4:17 PM, Etsuro Fujita
>> mailto:fujita.ets...@lab.ntt.co.jp>> wrote:
>>
>
> (2014/06/30 17:47), Ashutosh Bapat wrote:
>>
>
> BTW, why aren't you using the t
1 - 100 of 177 matches
Mail list logo
