(2011/12/14 15:34), Shigeru Hanada wrote:
(2011/12/13 22:00), Etsuro Fujita wrote:
Thank you for your effectiveness experiments and proposals for
improvements. I updated the patch according to your proposals.
Attached is the updated version of the patch.
I think this patch could be marked
the same check in the planner?
I've created a patch using this approach.
I've rebased the above patch against the latest head. Could you review the
patch? If you have no objection, I'd like to mark the patch ready for
committer.
Thanks,
Best regards,
Etsuro Fujita
unused-targets-20130618.patch
attached the patch.
Thanks,
Best regards,
Etsuro Fujita
unused-targets-20130618-2.patch
Description: Binary data
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
Hi Alexander,
Thank you for the check! I marked the patch ready for committer.
Best regards,
Etsuro Fujita
From: Alexander Korotkov [mailto:aekorot...@gmail.com]
Sent: Wednesday, June 19, 2013 1:26 AM
To: Etsuro Fujita
Cc: Tom Lane; pgsql-hackers
Subject: Re: [HACKERS] Patch
the removability check in adjust_targetlist() so that the resjunk
column is not used in GROUP BY, DISTINCT ON and *window PARTITION/ORDER BY*,
besides ORDER BY. No? I am open to any comments.
Thanks,
Best regards,
Etsuro Fujita
From: Hitoshi Harada [mailto:umi.tan...@gmail.com]
Sent
From: Hitoshi Harada [mailto:umi.tan...@gmail.com]
I guess the patch works fine, but what I'm saying is it might be limited to
small use cases. Another instance of this that I can think of is ORDER BY
clause
of window specifications, which you may want to remove from the target list
as
From: Hitoshi Harada [mailto:umi.tan...@gmail.com]
I tried several ways but I couldn't find big problems. Small typo:
s/rejunk/resjunk/
Thank you for the review. Attached is an updated version of the patch.
Thanks,
Best regards,
Etsuro Fujita
unused-targets-20130621.patch
Description
From: Alvaro Herrera [mailto:alvhe...@2ndquadrant.com]
Etsuro Fujita escribió:
From: Hitoshi Harada [mailto:umi.tan...@gmail.com]
I tried several ways but I couldn't find big problems. Small typo:
s/rejunk/resjunk/
Thank you for the review. Attached is an updated version
with Robert.
Sorry for the delay in my review.
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
Attached is a small typo fix patch.
Thanks,
Best regards,
Etsuro Fujita
typofix-20130731.patch
Description: Binary data
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
it to be aware of
the cost implications though, at least for grouping_planner's choices.
+1 for improving KNNGist-style queries.
Sorry for the late response.
Thanks,
Best regards,
Etsuro Fujita
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your
to create a dummy RelOptInfo representing an empty set of relations,
which is a bit weird but probably not too unreasonable when all's said and
done.
I think this is reasonable.
Thanks,
Best regards,
Etsuro Fujita
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes
/message-id/14993.1354552...@sss.pgh.pa.us
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
to locate the thread
based on this description, but couldn't locate it.
Please see
http://www.postgresql.org/message-id/6543.1375470...@sss.pgh.pa.us
Best regards,
Etsuro Fujita
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http
of processing for EquivalenceClasses and PathKeys).
Thanks,
Best regards,
Etsuro Fujita
ordinality-path-20130813.patch
Description: Binary data
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
attached a patch.
Thanks,
Best regards,
Etsuro Fujita
REL9_3_BETA2_release.patch
Description: Binary data
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
ISTM the README contains incorrect information and requires revision to reflect
the current code. Please find attached a patch. ISTM the patch needs to be
applied to all active branches.
Thanks,
Best regards,
Etsuro Fujita
optimizer-readme.patch
Description: Binary data
--
Sent via pgsql
From: Tom Lane [mailto:t...@sss.pgh.pa.us]
Etsuro Fujita fujita.ets...@lab.ntt.co.jp writes:
ISTM the README contains incorrect information and requires revision
to reflect the current code. Please find attached a patch. ISTM the
patch needs to be applied to all active branches
I wrote:
I've reworked on the patch.
Attached is an updated version of the patch. In that version the code for the
newly added function build_function_pathkeys() has been made more simple by
using the macro INTEGER_BTREE_FAM_OID.
Thanks,
Best regards,
Etsuro Fujita
ordinality-path-20130815
From: 'Bruce Momjian' [mailto:br...@momjian.us]
On Tue, Aug 13, 2013 at 05:59:05PM +0900, Etsuro Fujita wrote:
Thanks for the many suggestions on improving the 9.3 release notes.
There were many ideas I would have never thought of. Please keep
the
suggestions
coming.
One
I ran into a typo. Attached is a patch.
Thanks,
Best regards,
Etsuro Fujita
typofix-20130917.patch
Description: Binary data
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
I think the document in advanced.sgml should be corrected, though I might
misunderstand the rules of usage. Attached is a patch.
Thanks,
Best regards,
Etsuro Fujita
docsfix-20130917.patch
Description: Binary data
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make
, this patch inserts new entries into the pending list
temporarily and immediately moves them to the main GIN data structure using
ginInsertCleanup(). Am I right? If so, that is obviously inefficient.
Sorry for the delay.
Best regards,
Etsuro Fujita
--
Sent via pgsql-hackers mailing list (pgsql
to update performance for the
fast update technique set this parameter to a large value, users that give
weight not only to update performance but to search performance set this
parameter to a small value. What do you think about this?
Thanks,
Best regards,
Etsuro Fujita
--
Sent via pgsql-hackers
. So I'd like to mark
this patch as Returned with Feedback. Is it OK?
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,
ISTM the document in alter_foreign_data_wrapper.sgml and the comment in
foreigncmds.c should be updated. Please find attached a patch.
Thanks,
Best regards,
Etsuro Fujita
fdw-doc-update.patch
Description: Binary data
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org
,
Best regards,
Etsuro Fujita
fdw-doc-update-2.patch
Description: Binary data
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
=0)
(actual time=22.821..22.821 rows=100047 loops=1)
Index Cond: ((col2 = 0.01::double precision) AND (col2 = 0.02::double
precision))
Total runtime: 1129.334 ms
(7 rows)
Comments welcome.
Thanks,
Best regards,
Etsuro Fujita
explain-bitmapscan-20131031.patch
Description: Binary data
.
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,
ISTM the code in tidbitmap.c should be improved. Patch attached. I think
this patch increases the efficiency a bit.
Thanks,
Best regards,
Etsuro Fujita
diff --git a/src/backend/nodes/tidbitmap.c b/src/backend/nodes/tidbitmap.c
index 3ef0112..43628ac 100644
--- a/src/backend
a bit efficiently.
I'll add the patch to the 2013-11 CF. Any comments are welcome.
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
.
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'd like to look at this version of the patch more closely, then.
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
From: Amit Khandekar [mailto:amit.khande...@enterprisedb.com]
On 1 November 2013 16:32, Etsuro Fujita fujita.ets...@lab.ntt.co.jp wrote:
From: Fujii Masao [mailto:masao.fu...@gmail.com]
I'm not sure if it's good idea to show the number of the fetches because it
seems difficult to tune
,
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
Amit Khandekar wrote:
On 25 November 2013 13:37, Etsuro Fujita fujita.ets...@lab.ntt.co.jp wrote:
So, my question is, we should show the number of exact/lossy pages in a
TIDBitmap, not the number of these pages that has been fetched in the bitmap
heap scan?
Yes, I agree that rather than
).
Understood. Thank you for the detailed information. But I'm not sure it's
worth complicating the code. What use cases are you thinking?
Thanks,
Best regards,
Etsuro Fujita
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http
as are
user attributes because that makes the code more simple. Yes, as you
mention, it's not necessarily guaranteed that system attributes have the
uniqueness property in general, but that's another problem.
Thanks,
Best regards,
Etsuro Fujita
--
Sent via pgsql-hackers mailing list (pgsql-hackers
is
more complicated than what the patch really does, I've simplified the patch.
Attached is an updated version of the patch. Could you review the patch?
Thanks,
Best regards,
Etsuro Fujita
pathkey_and_uniqueindx_v6_20131128.patch
Description: Binary data
--
Sent via pgsql-hackers mailing list
I wrote:
I've modified the patch to work in such a way. Also, as ISTM the patch
is more complicated than what the patch really does, I've simplified the
patch.
I've revised the patch a bit. Please find attached the patch.
Thanks,
Best regards,
Etsuro Fujita
the all-or-nothing
decision.
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
. So, I modified the patch to do the all-or-nothing
decision.
Here I mean the optimality for use in merge joins.
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
on the inside of a nestloop join. For memory usage
and desired memory I think the maximum values would be fine.) I re-wish to
know your opinion.
Thanks,
Best regards,
Etsuro Fujita
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription
Robert Haas wrote:
On Fri, Dec 6, 2013 at 5:02 AM, Etsuro Fujita
fujita.ets...@lab.ntt.co.jp
wrote:
Though at first I agreed on this, while working on this I start to
think information about (2) is enough for tuning work_mem. Here are
examples using a version under development, where
Kyotaro HORIGUCHI wrote:
I'm convinced of the validity of your patch. I'm satisfied with it. Thank
you.
Thank you for the reply.
Then, if there are no objections of others, I'll mark this as Ready for
Committer.
Thanks,
Best regards,
Etsuro Fujita
--
Sent via pgsql-hackers mailing list
I wrote:
Kyotaro HORIGUCHI wrote:
I'm convinced of the validity of your patch. I'm satisfied with it.
Then, if there are no objections of others, I'll mark this as Ready for
Committer.
Done.
Thanks,
Best regards,
Etsuro Fujita
--
Sent via pgsql-hackers mailing list (pgsql-hackers
)
- Bitmap Index Scan on demo_col2_idx (cost=0.00..2047.71 rows=97528
width=0) (actual time=25.884..25.884 rows=99833 loops=1)
Index Cond: ((col2 = 0.01::double precision) AND (col2 =
0.02::double precision))
Total runtime: 1687.047 ms
(8 rows)
Thanks,
Best regards,
Etsuro Fujita
explain
This is a small patch a bit improving a comment in
src/backend/commands/copy.c.
Thanks,
Best regards,
Etsuro Fujita
copy-comment.patch
Description: Binary data
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http
This is a small patch to fix a typo in src/backend/utils/mmgr/README.
Thanks,
Best regards,
Etsuro Fujita
typofix.patch
Description: Binary data
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref
Peter Eisentraut wrote:
On 12/24/13, 1:33 AM, Etsuro Fujita wrote:
This is a small patch to fix a typo in src/backend/utils/mmgr/README.
I don't think that change is correct.
I've fixed the patch, though that might be still wrong. I'm not a native
English speaker ;). Please find attached
.
Attached is a new version of the patch, which shows only fetch block
information and memory usage information. I'll add this to the upcoming CF.
Thanks,
Best regards,
Etsuro Fujita
explain-bitmapscan-20131227.patch
Description: Binary data
--
Sent via pgsql-hackers mailing list (pgsql
Tom Lane wrote:
Etsuro Fujita fujita.ets...@lab.ntt.co.jp writes:
[ pathkey_and_uniqueindx_v7_20131203.patch ]
I started to look at this patch. I don't understand the reason for the
foreach loop in index_pathkeys_are_extensible (and the complete lack of
comments in the patch isn't helping
*/
if (a-nentries == 0)
return;
***
Sorry for the delay.
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
be a overdone.
The following modification to v7 does this.
It seems to me that this would be reasonable at least as the first step and
that it would be better to leave more close checking for future work.
Thanks,
Best regards,
Etsuro Fujita
--
Sent via pgsql-hackers mailing list (pgsql-hackers
Robert Haas wrote:
On Mon, Jan 6, 2014 at 9:40 PM, Etsuro Fujita
fujita.ets...@lab.ntt.co.jp
wrote:
Thank you for taking time to look at this patch. The peak memory
usage for the discarded bitmap *can* be reflected in the number
displayed for the bitmap heap scan by the following code
find attached a patch.
Thanks,
Best regards,
Etsuro Fujita
explain-bitmapscan-20140110.patch
Description: Binary data
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
.
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 ran into a typo in src/include/access/gin_private.h. Patch attached.
Thanks,
Best regards,
Etsuro Fujita
gin_private.h-typo.patch
Description: Binary data
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org
at this patch more closely.
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
(2014/01/25 11:27), Shigeru Hanada wrote:
2014/1/23 Etsuro Fujita fujita.ets...@lab.ntt.co.jp:
Shigeru Hanada wrote:
Though this would be debatable, in current implementation, constraints
defined on a foreign table (now only NOT NULL and CHECK are supported)
are not enforced during INSERT
not.
I'd like to vote for the idea of silently forcing any constraints on a
foreign-table into assertion mode. No new syntax and better documentation.
Thanks,
Best regards,
Etsuro Fujita
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription
(ie ATSimpleRecursion())
should be modified for the ALTER COLUMN SET STORAGE case.
I just wanted to quickly tell you this for you to take time to consider.
Thanks,
Best regards,
Etsuro Fujita
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your
(2014/01/28 0:55), Atri Sharma wrote:
On 27-Jan-2014, at 21:03, David Fetter da...@fetter.org wrote:
On Mon, Jan 27, 2014 at 05:06:19PM +0900, Etsuro Fujita wrote:
Hi Hanada-san,
While still reviwing this patch, I feel this patch has given enough
consideration to interactions with other
(2014/01/27 21:49), Shigeru Hanada wrote:
2014-01-27 Etsuro Fujita fujita.ets...@lab.ntt.co.jp:
(2014/01/25 11:27), Shigeru Hanada wrote:
Yeah, the consistency is essential for its ease of use. But I'm not sure
that inherited stats ignoring foreign tables is actually useful for query
(2014/01/28 22:01), Etsuro Fujita wrote:
(2014/01/27 21:49), Shigeru Hanada wrote:
Is it too big change that making ANALYZE command to handle foreign
tables too even if no table name was specified? IIRC, performance
issue was the reason to exclude foreign tables from auto-analyze
processing
(2014/02/01 8:01), Tom Lane wrote:
Bruce Momjian br...@momjian.us writes:
On Thu, Aug 15, 2013 at 07:25:17PM +0900, Etsuro Fujita wrote:
Attached is an updated version of the patch. In that version the code for
the
newly added function build_function_pathkeys() has been made more simple
* INTO local_table FROM foreign_table did create a
new local table of columns having the storage types associated with
those of a foreign table?
Thanks,
Best regards,
Etsuro Fujita
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http
(2014/02/04 20:56), Robert Haas wrote:
On Sun, Feb 2, 2014 at 10:15 PM, Etsuro Fujita
fujita.ets...@lab.ntt.co.jp wrote:
Allowing ALTER COLUMN SET STORAGE on foreign tables would make sense if for
example, SELECT * INTO local_table FROM foreign_table did create a new
local table of columns
Hi Hanada-san,
Sorry for the delay.
(2014/01/30 14:01), Shigeru Hanada wrote:
2014-01-27 Etsuro Fujita fujita.ets...@lab.ntt.co.jp:
While still reviwing this patch, I feel this patch has given enough
consideration to interactions with other commands, but found the following
incorrect
(2014/02/07 21:31), Etsuro Fujita wrote:
So, I've modified the patch so
that we continue to disallow SET STORAGE on a foreign table *in the same
manner as before*, but, as your patch does, allow it on an inheritance
hierarchy that contains foreign tables, with the semantics that we
Why does create_foreignscan_path() not set the rowcounts based on
ParamPathInfo when the path is a parameterized path? Please find
attached a patch.
Thanks,
Best regards,
Etsuro Fujita
*** a/src/backend/optimizer/util/pathnode.c
--- b/src/backend/optimizer/util/pathnode.c
(2014/02/18 12:03), Tom Lane wrote:
Etsuro Fujita fujita.ets...@lab.ntt.co.jp writes:
Why does create_foreignscan_path() not set the rowcounts based on
ParamPathInfo when the path is a parameterized path?
The calling FDW is supposed to do that; note the header comment.
Understood. However
From: Shigeru Hanada [mailto:shigeru.han...@gmail.com]
2014-02-10 21:00 GMT+09:00 Etsuro Fujita fujita.ets...@lab.ntt.co.jp:
(2014/02/07 21:31), Etsuro Fujita wrote:
So, I've modified the patch so
that we continue to disallow SET STORAGE on a foreign table *in the
same manner as before
(2014/02/19 12:12), Kyotaro HORIGUCHI wrote:
At Tue, 18 Feb 2014 19:24:50 +0900, Etsuro Fujita wrote
From: Shigeru Hanada [mailto:shigeru.han...@gmail.com]
I'm not sure that allowing ALTER TABLE against parent table affects
descendants even some of them are foreign table. I think the rule
doesn't
seem to be a matter of 'ALTER TABLE'. Could you tell me how this
is related to 'ALTER TABLE'?
These are not related to ALTER TABLE. [NO] INHERIT parent_table (and
ADD/DROP CONSTRAINT) are what I think should be newly allowed to apply
to foreign tables directly.
Thanks,
Best regards,
Etsuro
(2014/02/20 19:55), Etsuro Fujita wrote:
(2014/02/20 15:47), Kyotaro HORIGUCHI wrote:
Although my concerns here are only two points,
unanticipated application and maintenancibility. I gave a
consideration on these issues again.
Sorry, I misunderstood what you mean by unanticipated
not sure it's worth implementing such a
checking mechanism in the recursive altering operation...
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
This is a small patch to improve comments in tablecmds.c. Please find
attached a patch.
Thanks,
Best regards,
Etsuro Fujita
diff --git a/src/backend/commands/tablecmds.c b/src/backend/commands/tablecmds.c
index 08b037e..ed9d206 100644
--- a/src/backend/commands/tablecmds.c
+++ b/src/backend
-table case
to reparameterize_path(). And I think we should introduce a new FDW
routine, say ReparameterizeForeignPath() because the processing would be
performed best by the FDW itself.
Comments are welcome!
Thanks,
Best regards,
Etsuro Fujita
--
Sent via pgsql-hackers mailing list (pgsql
(2014/02/18 12:37), Tom Lane wrote:
Etsuro Fujita fujita.ets...@lab.ntt.co.jp writes:
(2014/02/18 12:03), Tom Lane wrote:
The calling FDW is supposed to do that; note the header comment.
However, ISTM postgresGetForeignPaths() doesn't work like
that. It uses the same rowcount for all paths
be implemented as a separate patch.
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
.
[1] http://www.postgresql.org/message-id/530c7464.6020...@lab.ntt.co.jp
Best regards,
Etsuro Fujita
*** a/contrib/file_fdw/file_fdw.c
--- b/contrib/file_fdw/file_fdw.c
***
*** 117,122 static void fileGetForeignRelSize(PlannerInfo *root,
--- 117,126
static void
,
Best regards,
Etsuro Fujita
*** a/contrib/file_fdw/file_fdw.c
--- b/contrib/file_fdw/file_fdw.c
***
*** 117,122 static void fileGetForeignRelSize(PlannerInfo *root,
--- 117,126
static void fileGetForeignPaths(PlannerInfo *root,
RelOptInfo
(2014/03/20 21:59), Etsuro Fujita wrote:
Here is a simple example for the case where the
use_remote_estimate option is true:
Sorry, I incorrectly wrote it. The following example is for the case
where the option is *false*, as you see.
# On mydatabase
mydatabase=# CREATE TABLE mytable (id
compromise by putting a note to CF-app that last judgement
is left to committer.
OK So, if there are no objections of other, I'll mark this patch as
ready for committer and do that.
Thanks,
Best regards,
Etsuro Fujita
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make
and the gain by
the previous optimization don't seem to be significant..
Yeah, that's true. I have to admit that the previous optimization is
nonsense.
Thanks,
Best regards,
Etsuro Fujita
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription
information, the same assertion can be found in
create_foreignscan_plan().
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
||
569 relkind ==
RELKIND_FOREIGN_TABLE));
Is this intended to support an OID column on foreign tables in future?
Thanks,
Best regards,
Etsuro Fujita
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your
as is. So, all we need to do is show important use
cases that prove the effectiveness of the patch. Sorry, I can't come up
with a good idea, though.
Thanks,
Best regards,
Etsuro Fujita
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http
Attached is a patch to improve the manual page for the ALTER TABLE command.
Thanks,
Best regards,
Etsuro Fujita
diff --git a/doc/src/sgml/ref/alter_table.sgml
b/doc/src/sgml/ref/alter_table.sgml
index 0b08f83..ce67c71 100644
--- a/doc/src/sgml/ref/alter_table.sgml
+++ b/doc/src/sgml/ref
(2014/04/09 1:23), Robert Haas wrote:
On Tue, Apr 8, 2014 at 5:05 AM, Etsuro Fujita
fujita.ets...@lab.ntt.co.jp wrote:
Attached is a patch to improve the manual page for the ALTER TABLE command.
Do we really need to add a section for type_name when we already
have a section for OF type_name
to do with the query_pathkeys.
I think that the two pathkeys would be proved to be equal, if the both
conditions are satisfied.
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
(2014/04/10 22:25), Tom Lane wrote:
Etsuro Fujita fujita.ets...@lab.ntt.co.jp writes:
(2014/04/10 0:08), Tom Lane wrote:
TBH I think that's barely the tip of the iceberg of cases where this
patch will get the wrong answer.
Also, I don't see it doing anything to check the ordering
(2014/04/09 12:03), Etsuro Fujita wrote:
(2014/04/09 1:23), Robert Haas wrote:
On Tue, Apr 8, 2014 at 5:05 AM, Etsuro Fujita
fujita.ets...@lab.ntt.co.jp wrote:
Attached is a patch to improve the manual page for the ALTER TABLE
command.
Do we really need to add a section for type_name when we
Attached is a small patch to improve create_foreign_table.sgml.
Thanks,
Best regards,
Etsuro Fujita
diff --git a/doc/src/sgml/ref/create_foreign_table.sgml
b/doc/src/sgml/ref/create_foreign_table.sgml
index 06a7087..4a8cf38 100644
--- a/doc/src/sgml/ref/create_foreign_table.sgml
+++ b/doc/src
(2014/04/14 23:53), Robert Haas wrote:
On Fri, Apr 11, 2014 at 5:00 AM, Etsuro Fujita
fujita.ets...@lab.ntt.co.jp wrote:
Attached is an updated version of the patch.
I applied the first two hunks of this, which seem like clear
oversights; and also the bit fixing the constraint_name language
)
Output: onemillion.id
- Seq Scan on public.onemillion (cost=0.00..20834.00
rows=99918 width=4)
Output: onemillion.id
Filter: (onemillion.data '0.9'::text)
Planning time: 0.215 ms
(14 rows)
Thanks,
Best regards,
Etsuro Fujita
--
Sent via
(2014/04/16 22:16), Hannu Krosing wrote:
On 04/16/2014 01:35 PM, Etsuro Fujita wrote:
Maybe I'm missing something, but I think that you can do what I think
you'd like to do by the following procedure:
No, what I'd like PostgreSQL to do is to
1. select the id+set from local table
2. select
The attached improves a document in src/backend/access/gin/README.
Thanks,
Best regards,
Etsuro Fujita
diff --git a/src/backend/access/gin/README b/src/backend/access/gin/README
index 3f0c3e2..8a71d28 100644
--- a/src/backend/access/gin/README
+++ b/src/backend/access/gin/README
@@ -181,7 +181,7
The attached improves a comment in gin_private.h a little bit.
Thanks,
Best regards,
Etsuro Fujita
diff --git a/src/include/access/gin_private.h b/src/include/access/gin_private.h
index 81a3bee..3aa4276 100644
--- a/src/include/access/gin_private.h
+++ b/src/include/access/gin_private.h
101 - 200 of 949 matches
Mail list logo
