> , On Wed, Aug 26, 2015 at 4:05 AM, Kouhei Kaigai <kai...@ak.jp.nec.com> wrote:
> >> On 2015/08/26 16:07, Kouhei Kaigai wrote:
> >> I wrote:
> >> >> Maybe I'm missing something, but why do we need such a flexiblity for
> >> >> the c
On 27/08/15 13:36, Kouhei Kaigai wrote:
[...]
My measurement is done on v9.5 based system. So, it also seems to me
replacement of CHAR(n) by VARCHAR(n) will make sense.
Is there any reason to not simply use text instead of CHAR(n) or VARCHAR(n)?
Text is also welcome, of course.
--
NEC
As I have said repeatedly, it is software design decision by the author
of extension. Even if it consumes 100 times larger memory and 1000 times
slower, it is his decision and responsibility.
Why he has to be forced to use a particular logic despite his intension?
I don't understand
In addition, you may misunderstand the proposition of mine above.
You can check RelOptInfo-fdw_private on top of the GetForeignJoinPaths,
then, if it is second or later invocation, you can check cost of the
alternative path kept in the ForeignPath node previously constructed.
If
Kaigai wrote:
On 2015/08/26 16:07, Kouhei Kaigai wrote:
Even if we enforce them a new interface specification comfortable to
RDBMS,
we cannot guarantee it is also comfortable to other type of FDW drivers.
Specifically, what kind of points about the patch are specific to RDBMS
On 2015/08/26 16:07, Kouhei Kaigai wrote:
I wrote:
Maybe I'm missing something, but why do we need such a flexiblity for
the columnar-stores?
Even if we enforce them a new interface specification comfortable to RDBMS,
we cannot guarantee it is also comfortable to other type of FDW
On 2015-08-26 00:55:48 +, Kouhei Kaigai wrote:
As Tom pointed out, the primary reason why CustomScan required provider
to save its private data on custom_exprs/custom_private were awareness
of copyObject().
Well, a callback brings that with it as well. I do think it makes sense
but optimizer made unreasonable
plan
On Mon, Aug 17, 2015 at 6:40 AM, Kouhei Kaigai kai...@ak.jp.nec.com wrote:
I think SortSupport logic provides a reasonable way to solve this
kind of problem. For example, btint4sortsupport() informs a function
pointer of the fast version of comparator
-Original Message-
From: Tom Lane [mailto:t...@sss.pgh.pa.us]
Sent: Thursday, August 27, 2015 9:03 AM
To: Qingqing Zhou
Cc: Kaigai Kouhei(海外 浩平); Greg Stark; PostgreSQL-development
Subject: Re: [HACKERS] Our trial to TPC-DS but optimizer made unreasonable
plan
Qingqing Zhou
On 2015/08/26 18:01, Kouhei Kaigai wrote:
You may think execution of alternative plan is the best way for EPQ
rechecks,
however, other folks may think their own implementation is the best for
EPQ
rechecks. I never argue which approach is better.
What I point out is freedom
On 2015/08/25 10:18, Kouhei Kaigai wrote:
How about your opinion towards the solution?
Likely, what you need to do are...
1. Save the alternative path on fdw_paths when foreign join push-down.
GetForeignJoinPaths() may be called multiple times towards a particular
joinrel
On 2015-08-25 14:42:32 -0400, Tom Lane wrote:
Andres Freund and...@anarazel.de writes:
Since we already have CustomScan-methods, it seems to be rather
reasonable to have a CopyCustomScan callback and let it do the copying
of the private data if present? Or possibly of the whole node,
On Fri, Aug 21, 2015 at 7:40 PM, Robert Haas robertmh...@gmail.com wrote:
On Tue, Aug 18, 2015 at 11:27 PM, Amit Kapila amit.kapil...@gmail.com
wrote:
Here is one other issue I found. Existing code assumes a TOC segment has
only one contents per node type, so it uses pre-defined key
...@postgresql.org
[mailto:pgsql-hackers-ow...@postgresql.org] On Behalf Of Kouhei Kaigai
Sent: Thursday, August 13, 2015 10:13 AM
To: Etsuro Fujita; Robert Haas
Cc: PostgreSQL-development; 花田茂
Subject: Re: [HACKERS] Foreign join pushdown vs EvalPlanQual
Fujita-san,
The attached patch
Hello KaiGai-san,
On 08/21/2015 02:28 AM, Kouhei Kaigai wrote:
...
But what is the impact on queries that actually need more than 1GB
of buckets? I assume we'd only limit the initial allocation and
still allow the resize based on the actual data (i.e. the 9.5
improvement), so
On 08/19/2015 03:53 PM, Tom Lane wrote:
I don't see anything very wrong with constraining the initial
allocation to 1GB, or even less. That will prevent consuming insane
amounts of work_mem when the planner's rows estimate is too high
rather than too low. And we do have the ability to
On Mon, Aug 17, 2015 at 9:40 AM, Kouhei Kaigai kai...@ak.jp.nec.com wrote:
I think SortSupport logic provides a reasonable way to solve this
kind of problem. For example, btint4sortsupport() informs a function
pointer of the fast version of comparator (btint4fastcmp) which takes
two Datum
Hello Kondo-san,
I briefly checked your patch. Let me put some comments about
its design and implementation, even though I have no arguments
towards its concept. :-)
* Construction of RelOptInfo
In your patch, try_hashjoin_pushdown() called by try_hashjoin_path()
constructs RelOptInfo of the
I reported a similar issue before.
* Re: DBT-3 with SF=20 got failed
http://www.postgresql.org/message-id/557a19d1.9050...@2ndquadrant.com
I didn't get a server crash at that time, however, palloc() complained
about request size = 1GB.
So, we may need a couple of overhaul around HashJoin to
Kouhei Kaigai kai...@ak.jp.nec.com wrote:
longlbuckets;
lbuckets = 1 my_log2(hash_table_bytes / bucket_size);
Assert(nbuckets 0);
In my case, the hash_table_bytes was 101017630802, and bucket_size was 48.
So, my_log2(hash_table_bytes / bucket_size
On Mon, Aug 17, 2015 at 6:40 AM, Kouhei Kaigai kai...@ak.jp.nec.com wrote:
Here is one other thing I could learn from TPC-DS benchmark.
The attached query is Q4 of TPC-DS, and its result was towards SF=100.
It took long time to compete (about 30min), please see the attached
EXPLAIN
number of rows
On 19 August 2015 at 08:54, Kevin Grittner kgri...@ymail.com wrote:
Kouhei Kaigai kai...@ak.jp.nec.com wrote:
longlbuckets;
lbuckets = 1 my_log2(hash_table_bytes / bucket_size);
Assert(nbuckets 0);
In my
Hello,
I noticed ExecChooseHashTableSize() in nodeHash.c got failed by
Assert(nbuckets 0), when crazy number of rows are expected.
BACKTRACE:
#0 0x003f79432625 in raise () from /lib64/libc.so.6
#1 0x003f79433e05 in abort () from /lib64/libc.so.6
#2 0x0092600a in
/ PG-Strom Project
KaiGai Kohei kai...@ak.jp.nec.com
-Original Message-
From: pgsql-hackers-ow...@postgresql.org
[mailto:pgsql-hackers-ow...@postgresql.org] On Behalf Of Kouhei Kaigai
Sent: Thursday, August 13, 2015 8:23 PM
To: Greg Stark
Cc: PostgreSQL-development
Subject: Re
On Thu, Aug 13, 2015 at 2:49 AM, Kouhei Kaigai kai...@ak.jp.nec.com wrote:
In fact, cost of HashJoin underlying Sort node is:
- Hash Join (cost=621264.91..752685.48 rows=1 width=132)
On the other hands, NestedLoop on same place is:
- Nested Loop (cost=0.00..752732.26 rows=1
On Fri, Aug 7, 2015 at 2:15 PM, Kouhei Kaigai kai...@ak.jp.nec.com wrote:
On Sat, Aug 1, 2015 at 6:39 PM, Kouhei Kaigai kai...@ak.jp.nec.com
wrote:
If we pull Funnel here, I think the plan shall be as follows:
Funnel
-- SeqScan on rel1
pushdown vs EvalPlanQual
On 2015/08/12 7:21, Robert Haas wrote:
On Fri, Aug 7, 2015 at 3:37 AM, Kouhei Kaigai kai...@ak.jp.nec.com wrote:
I could have a discussion with Fujita-san about this topic.
Also, let me share with the discussion towards entire solution.
The primitive reason
To: Robert Haas; Kaigai Kouhei(海外 浩平)
Cc: PostgreSQL-development; 花田茂
Subject: Re: [HACKERS] Foreign join pushdown vs EvalPlanQual
On 2015/08/12 7:21, Robert Haas wrote:
On Fri, Aug 7, 2015 at 3:37 AM, Kouhei Kaigai kai...@ak.jp.nec.com
wrote:
I could have a discussion with Fujita-san
(Please read this message on wide display)
Our team recently tries to run TPC-DS benchmark to know capability of
PostgreSQL towards typical analytic queries.
TPC-DS defines about 100 complicated queries. We noticed optimizer made
unreasonable execution plan towards some of queries.
Here is an
people's comment.
--
NEC Business Creation Division / PG-Strom Project
KaiGai Kohei kai...@ak.jp.nec.com
-Original Message-
From: pgsql-hackers-ow...@postgresql.org
[mailto:pgsql-hackers-ow...@postgresql.org] On Behalf Of Kouhei Kaigai
Sent: Saturday, August 01, 2015 10:35 PM
To: Robert
On Sat, Aug 1, 2015 at 6:39 PM, Kouhei Kaigai kai...@ak.jp.nec.com wrote:
On Tue, Jul 28, 2015 at 6:08 PM, Kouhei Kaigai kai...@ak.jp.nec.com
wrote:
I am not sure, but what problem do you see in putting Funnel node
for one of the relation scans and not for the others
On Mon, Apr 16, 2012 at 06:25:15AM -0400, Noah Misch wrote:
I observed these inconsistencies in node support functions:
A fresh audit found the attached problems new in 9.5[1]. Most are cosmetic
INT/UINT or field order corrections. The non-cosmetic changes involve
CustomPath, CustomScan,
On Tue, Jul 28, 2015 at 6:08 PM, Kouhei Kaigai kai...@ak.jp.nec.com wrote:
On Tue, Jul 28, 2015 at 7:59 AM, Kouhei Kaigai kai...@ak.jp.nec.com
wrote:
-Original Message-
From: pgsql-hackers-ow...@postgresql.org
[mailto:pgsql-hackers-ow...@postgresql.org
On Fri, Jul 3, 2015 at 6:25 AM, Etsuro Fujita
fujita.ets...@lab.ntt.co.jp wrote:
Can't FDWs get the join information through the root, which I think we would
pass to the API as the argument?
This is exactly what Tom suggested originally, and it has some appeal,
but neither KaiGai nor I
[mailto:pgsql-hackers-ow...@postgresql.org] On Behalf Of Kouhei Kaigai
Sent: Thursday, July 30, 2015 8:45 AM
To: Amit Kapila
Cc: Robert Haas; Gavin Flower; Jeff Davis; Andres Freund; Amit Langote; Amit
Langote; Fabrízio Mello; Thom Brown; Stephen Frost; pgsql-hackers; Haribabu
Kommi
Subject: Re
Hello,
The attached patch fixes up my careless misses when custom_plans field was
added.
Please apply this fix.
Thanks,
--
NEC Business Creation Division / PG-Strom Project
KaiGai Kohei kai...@ak.jp.nec.com
pgsql-v9.5-fix-copy-custom-scan.patch
Description:
On Wed, Jul 29, 2015 at 7:32 PM, Kouhei Kaigai kai...@ak.jp.nec.com wrote:
Hi Amit,
Could you tell me the code intention around ExecInitFunnel()?
ExecInitFunnel() calls InitFunnel() that opens the relation to be
scanned by the underlying PartialSeqScan and setup ss_ScanTupleSlot
Hi Amit,
Could you tell me the code intention around ExecInitFunnel()?
ExecInitFunnel() calls InitFunnel() that opens the relation to be
scanned by the underlying PartialSeqScan and setup ss_ScanTupleSlot
of its scanstate.
According to the comment of InitFunnel(), it open the relation and
takes
On 2015-07-28 PM 09:58, Kouhei Kaigai wrote:
From my understanding of parallel seqscan patch, each worker's
PartialSeqScan asks for a block to scan using a shared parallel heap scan
descriptor that effectively keeps track of division of work among
PartialSeqScans in terms of blocks
On 27 July 2015 at 21:09, Kyotaro HORIGUCHI horiguchi.kyot...@lab.ntt.co.jp
wrote:
Hello, can I ask some questions?
I suppose we can take this as the analog of ParalleSeqScan. I
can see not so distinction between Append(ParalleSeqScan) and
KaiGai-san,
On 2015-07-27 PM 11:07, Kouhei Kaigai wrote:
Append
-- Funnel
-- PartialSeqScan on rel1 (num_workers = 4)
-- Funnel
-- PartialSeqScan on rel2 (num_workers = 8)
-- SeqScan on rel3
shall be rewritten to
Funnel
-- PartialSeqScan
On Tue, Jul 28, 2015 at 7:59 AM, Kouhei Kaigai kai...@ak.jp.nec.com wrote:
-Original Message-
From: pgsql-hackers-ow...@postgresql.org
[mailto:pgsql-hackers-ow...@postgresql.org] On Behalf Of Kouhei Kaigai
Sent: Monday, July 27, 2015 11:07 PM
To: Amit Kapila
On Sun, Jul 26, 2015 at 8:43 AM, Kouhei Kaigai kai...@ak.jp.nec.com wrote:
Hello,
I'm recently working/investigating on ParallelAppend feature
towards the next commit fest. Below is my design proposal.
1. Concept
--
Its concept is quite simple anybody might consider more
Hello, can I ask some questions?
I suppose we can take this as the analog of ParalleSeqScan. I
can see not so distinction between Append(ParalleSeqScan) and
ParallelAppend(SeqScan). What difference is there between them?
Append does not start to execute the second or later node until
first
-Original Message-
From: pgsql-hackers-ow...@postgresql.org
[mailto:pgsql-hackers-ow...@postgresql.org] On Behalf Of Kouhei Kaigai
Sent: Monday, July 27, 2015 11:07 PM
To: Amit Kapila
Cc: pgsql-hackers@postgresql.org; Robert Haas; Kyotaro HORIGUCHI
Subject: Re: [HACKERS] [DESIGN
: pgsql-hackers@postgresql.org
Subject: RE: [HACKERS] CustomScan and readfuncs.c
Kouhei Kaigai kai...@ak.jp.nec.com writes:
Under the investigation of ParallelAppend, I noticed here is a few
problems in CustomScan, that prevents to reproduce an equivalent
plan node on the background worker
On 2015/07/24 23:51, Kouhei Kaigai wrote:
On 2015/07/22 19:10, Etsuro Fujita wrote:
While working on the issue Foreign join pushdown vs EvalPlanQual, I
happened to notice odd behaviors of late row locking in FDWs.
I think the reason for that is because we don't check pushed-down quals
Hello,
Under the investigation of ParallelAppend, I noticed here is a few
problems in CustomScan, that prevents to reproduce an equivalent
plan node on the background worker from serialized string.
1. CustomScanMethods-TextOutCustomScan callback
On 04/01/2015 06:28 PM, Robert Haas wrote:
On Mon, Mar 30, 2015 at 1:28 AM, Michael Paquier
michael.paqu...@gmail.com wrote:
I've been thinking of bumping this patch to the June commitfest as the
patch only exists to provide the basic infrastructure for things like
parallel aggregation,
Kouhei Kaigai kai...@ak.jp.nec.com writes:
Under the investigation of ParallelAppend, I noticed here is a few
problems in CustomScan, that prevents to reproduce an equivalent
plan node on the background worker from serialized string.
1. CustomScanMethods-TextOutCustomScan callback
Hello,
I'm recently working/investigating on ParallelAppend feature
towards the next commit fest. Below is my design proposal.
1. Concept
--
Its concept is quite simple anybody might consider more than once.
ParallelAppend node kicks background worker process to execute
child nodes in
Hello Horiguchi-san,
As for ForeignScan, it is merely an API for FDW and does nothing
substantial so it would have nothing special to do. As for
postgres_fdw, current patch restricts one execution per one
foreign server at once by itself. We would have to provide
another execution
Fujita-san,
On 2015/07/22 19:10, Etsuro Fujita wrote:
While working on the issue Foreign join pushdown vs EvalPlanQual, I
happened to notice odd behaviors of late row locking in FDWs.
I think the reason for that is because we don't check pushed-down quals
inside an EPQ testing even if
, doesn't it?
On Thu, Jul 23, 2015 at 8:27 PM, Kouhei Kaigai kai...@ak.jp.nec.com wrote:
A dark side is, as discussed in this thread, complexity of EvalPlanQual.
RefetchForeignRow() returns a tuple based on foreign table definition,
on the other hands, whole-row var points a tuple based
On Wed, Jul 22, 2015 at 8:24 PM, Kouhei Kaigai kai...@ak.jp.nec.com wrote:
Indeed, this commit allows ForeignScan to have fdw_scan_tlist, even if
scanrelid 0, however, I'm uncertain about its reason/intention.
Does it a preparation for the upcoming target-list-pushdown??
I guess Tom
Hi Amit,
The latest v16 patch cannot be applied to the latest
master as is.
434873806a9b1c0edd53c2a9df7c93a8ba021147 changed various
lines in heapam.c, so it probably conflicts with this.
[kaigai@magro sepgsql]$ cat ~/patch/parallel_seqscan_v16.patch | patch -p1
patching file
If we have ParallelAppend node that kicks a background worker process for
each underlying child node in parallel, does ForeignScan need to do
something
special?
Although I don't see the point of the background worker in your
story but at least for ParalleMergeAppend, it would
Fujita-san,
Sorry for my late response.
The latest foreign-join pushdown patch allows fdw_scan_tlist to be set
to a targetlist even for simple foreign table scans. However, since I
think we assume that the test tuple of a foreign table for an EPQ
testing, whether it may be copied from the
-Original Message-
From: pgsql-hackers-ow...@postgresql.org
[mailto:pgsql-hackers-ow...@postgresql.org] On Behalf Of Kyotaro HORIGUCHI
Sent: Wednesday, July 22, 2015 4:10 PM
To: robertmh...@gmail.com
Cc: hlinn...@iki.fi; pgsql-hackers@postgresql.org
Subject: Re: [HACKERS]
-san,
On 2015/07/22 16:44, Kouhei Kaigai wrote:
The latest foreign-join pushdown patch allows fdw_scan_tlist to be set
to a targetlist even for simple foreign table scans. However, since I
think we assume that the test tuple of a foreign table for an EPQ
testing, whether it may be copied
Hi Yang,
I've performed some tests on pg_strom according to the wiki. But it seems that
queries run slower on GPU than CPU. Can someone shed a light on what's wrong
with my settings. My setup was Quadro K620 + CUDA 7.0 (For Ubuntu 14.10) +
Ubuntu 15.04. And the results was
:
,
-Original Message-
From: pgsql-hackers-ow...@postgresql.org
[mailto:pgsql-hackers-ow...@postgresql.org] On Behalf Of Josh Berkus
Sent: Thursday, July 23, 2015 2:49 AM
To: YANG; pgsql-hackers@postgresql.org; KaiGai Kohei
Subject: Re: [HACKERS] Queries runs slow on GPU with PG-Strom
for foreign table scans breaks EPQ
testing,
doesn't it?
On Wed, Jul 22, 2015 at 8:13 AM, Kouhei Kaigai kai...@ak.jp.nec.com wrote:
No, what I'm concerned about is the case when scanrelid 0.
Hmm. if scanrelid 0, then fdw_scan_tlist should be NIL.
I want to put Assert(scanrelid==0
of custom-scan (Re: [HACKERS] [v9.5]
Custom
Plan API)
On Wed, Jul 15, 2015 at 10:12 AM, Kouhei Kaigai kai...@ak.jp.nec.com wrote:
We never guarantee the interface compatibility between major version up.
If we add/modify interface on v9.6, it is duty for developer of extensions
to follow the new
-Original Message-
From: Tom Lane [mailto:t...@sss.pgh.pa.us]
Sent: Wednesday, July 15, 2015 5:47 AM
To: Robert Haas
Cc: Alvaro Herrera; hlinnaka; Kaigai Kouhei(海外 浩平); Michael Paquier; Jim
Nasby; Kohei KaiGai; PgHacker; Simon Riggs
Subject: Re: ctidscan as an example of custom-scan
Or, taking the example of a GpuScan node, it's essentially impossible
to persuade the planner to delegate any expensive function calculations,
aggregates, etc to such a node; much less teach it that that way is cheaper
than doing such things the usual way. So yeah, KaiGai-san may have a
That doesn't answer my question. I'm talking about a client and server
running on the same system with SELinux MLS policy so that getpeercon
will return the context of the client process unless it has explicitly
sets the socket create context . So again will postgresql if the
sepgsql module
So if I label a table with an SELinux context and the type of my
client connection does not have policy to be able to access the table
type will an AVC be generated and the access denied?
Of course, it depends on the policy of the system.
If client connection come from none-SELinux system,
Also, I don't want to stick on the assumption that relations involved in
remote join are all managed by same foreign-server no longer.
The following two ideas introduce possible enhancement of remote join
feature that involved local relations; replicated table or transformed
to VALUES()
On 2015/07/02 23:13, Kouhei Kaigai wrote:
To be honest, ISTM that it's difficult to do that simply and efficiently
for the foreign/custom-join-pushdown API that we have for 9.5. It's a
little late, but what I started thinking is to redesign that API so that
that API is called
Hi Fujita-san,
Sorry for my late.
On 2015/06/27 21:09, Kouhei Kaigai wrote:
BTW, if you try newer version of postgres_fdw foreign join patch,
please provide me to reproduce the problem/
OK
Did you forget to attach the patch, or v17 is in use?
Sorry, I made a mistake. The problem
Let me introduce a few cases we should pay attention.
Foreign/CustomScan node may stack; that means a Foreign/CustomScan node
may have child node that includes another Foreign/CustomScan node with
scanrelid==0.
(At this moment, ForeignScan cannot have child node, however, more
a. Infrastructure for parallel execution, like some of the stuff in
execparallel.c, heapam.c,tqueue.c, etc and all other generic
(non-nodes specific) code.
Did you consider passing tuples through the tqueue by reference rather
than copying? The page should be pinned by the worker
: [HACKERS] [v9.5]
Custom
Plan API)
On Tue, Jan 6, 2015 at 10:51 PM, Kouhei Kaigai kai...@ak.jp.nec.com wrote:
Jim, Thanks for your reviewing the patch.
The attached patch is revised one according to your suggestion,
and also includes bug fix I could found
On Thu, Jun 25, 2015 at 11:55 PM, Robert Haas robertmh...@gmail.com wrote:
On Thu, Jun 25, 2015 at 6:25 PM, Kouhei Kaigai kai...@ak.jp.nec.com wrote:
I have a serious open item reported 1.5 month ago then reminded
several times has not been fixed up yet
)
Cc: PostgreSQL-development
Subject: Re: [HACKERS] Foreign join pushdown vs EvalPlanQual
Hi KaiGai-san,
I'd like to work on this issue with you!
On 2015/06/25 10:48, Kouhei Kaigai wrote:
I'd like to suggest a solution that re-construct remote tuple according
to the fdw_scan_tlist
-Original Message-
From: pgsql-hackers-ow...@postgresql.org
[mailto:pgsql-hackers-ow...@postgresql.org] On Behalf Of Tom Lane
Sent: Friday, June 26, 2015 12:00 AM
To: pgsql-hackers@postgreSQL.org
Subject: [HACKERS] Schedule for 9.5alpha1
There was agreement at the PGCon dev
Fujita-san,
Does it make sense to put the result tuple of remote join on evety
estate-es_epqTupleSet[] slot represented by this ForeignScan if
scanrelid==0?
Sorry, I misunderstood behavior of the es_epqTupleSet[].
I'd like to suggest a solution that re-construct remote tuple according
to the
-Original Message-
From: David Rowley [mailto:david.row...@2ndquadrant.com]
Sent: Tuesday, June 23, 2015 2:06 PM
To: Kaigai Kouhei(海外 浩平)
Cc: Robert Haas; pgsql-hackers@postgresql.org; Tom Lane
Subject: Re: [HACKERS] upper planner path-ification
On 23 June 2015 at 13:55, Kouhei
planner path-ification
On Tue, Jun 23, 2015 at 4:41 AM, Kouhei Kaigai kai...@ak.jp.nec.com wrote:
So, unless we don't find out a solution around planner, 2-phase aggregation
is
like a curry without rice
Simon and I spoke with Tom about this upper planner path-ification
problem at PGCon
-Original Message-
From: pgsql-hackers-ow...@postgresql.org
[mailto:pgsql-hackers-ow...@postgresql.org] On Behalf Of Robert Haas
Sent: Thursday, May 14, 2015 10:39 AM
To: pgsql-hackers@postgresql.org; Tom Lane
Subject: [HACKERS] upper planner path-ification
Hi,
I've been
On Sat, Jun 13, 2015 at 08:18:26PM -0300, Alvaro Herrera wrote:
Bruce Momjian wrote:
I have committed the first draft of the 9.5 release notes. You can view
the output here:
http://momjian.us/pgsql_docs/release-9-5.html
I noticed something while reading this and would like
To: Kaigai Kouhei(海外 浩平)
Cc: pgsql-hackers@postgreSQL.org
Subject: Re: [HACKERS] DBT-3 with SF=20 got failed
On Wed, Jun 10, 2015 at 9:57 PM, Kouhei Kaigai kai...@ak.jp.nec.com wrote:
Hello,
I got the following error during DBT-3 benchmark with SF=20.
psql:query21.sql:50: ERROR
Robert Haas robertmh...@gmail.com writes:
Tom, do you want to review this patch and figure out how to solve the
underlying problem? If not, I will take care of it. But I will be
unhappy if I put time and effort into this and then you insist on
changing everything afterwards, again.
[
On 2015-06-10 PM 01:42, Kouhei Kaigai wrote:
Let's assume a table which is partitioned to four portions,
and individual child relations have constraint by hash-value
of its ID field.
tbl_parent
+ tbl_child_0 ... CHECK(hash_func(id) % 4 = 0)
+ tbl_child_1 ... CHECK
Hello,
I got the following error during DBT-3 benchmark with SF=20.
psql:query21.sql:50: ERROR: invalid memory alloc request size 1073741824
psql:query21.sql:50: ERROR: invalid memory alloc request size 1073741824
It looks to me Hash node tries to 1GB area using palloc0(), but it exceeds
Hello,
It might be a corner case optimization, however, it looks
to me worth to share the idea and have discussion.
Table partition + Hash join pushdown
Hash-join logic works most effectively when inner relation
can be stored within a hash table. So, it is a
On Sat, May 30, 2015 at 9:03 PM, Kouhei Kaigai kai...@ak.jp.nec.com wrote:
Yesterday, JPUG held an unconference event at Tokyo, and
Hanada-san had a talk about join-pushdown feature of
postgres_fdw.
At this talk, someone proposed an interesting idea to
make join pushdown more aggressive
On Thu, Jun 4, 2015 at 9:40 PM, Kouhei Kaigai kai...@ak.jp.nec.com wrote:
Neat idea. This ties into something I've thought about and mentioned
before: what if the innerrel is local, but there's a replicated copy
on the remote server? Perhaps both cases are worth thinking about at
some
-Original Message-
From: pgsql-hackers-ow...@postgresql.org
[mailto:pgsql-hackers-ow...@postgresql.org] On Behalf Of Tom Lane
Sent: Thursday, May 28, 2015 5:35 AM
To: Robert Haas
Cc: Kaigai Kouhei(海外 浩平); Thom Brown; Kohei KaiGai; Shigeru Hanada;
pgsql-hackers@postgreSQL.org
-Strom Project
KaiGai Kohei kai...@ak.jp.nec.com
-Original Message-
From: pgsql-hackers-ow...@postgresql.org
[mailto:pgsql-hackers-ow...@postgresql.org] On Behalf Of Kouhei Kaigai
Sent: Friday, May 15, 2015 8:44 AM
To: Tom Lane; Kohei KaiGai
Cc: Robert Haas; Thom Brown; Shigeru
A possible compromise that we could perhaps still wedge into 9.5 is to
extend CustomPath with a List of child Paths, and CustomScan with a List
of child Plans, which createplan.c would know to build from the Paths,
and other modules would then also be aware of these children. I find that
* ctidscan as an example of custom-scan
This basically hasn't gotten any attention, which may mean nobody cares
enough to justify putting it in the tree. We need to either push it to
next CF or reject altogether.
Agreed. I was fine with never committing this. I don't think we have
Hello,
I tried to make patches for the three approaches.
Please don't think the option-3 serious proposition, however,
it is the only solution at this moment unfortunately.
In my understanding, we don't guarantee interface compatibility
across major version up, including the definitions of
Hi,
Let me back to the original concern and show possible options
we can take here. At least, the latest master is not usable to
implement custom-join logic without either of these options.
option-1)
Revert create_plan_recurse() to non-static function for extensions.
It is the simplest solution,
On 2015-05-10 21:26:26 -0400, Robert Haas wrote:
On Sun, May 10, 2015 at 8:41 PM, Tom Lane t...@sss.pgh.pa.us wrote:
This commit reverts create_plan_recurse() as static function.
Yes. I am not convinced that external callers should be calling that,
and would prefer not to enlarge
Kohei KaiGai kai...@kaigai.gr.jp writes:
I briefly checked your updates.
Even though it is not described in the commit-log, I noticed a
problematic change.
This commit reverts create_plan_recurse() as static function.
Yes. I am not convinced that external callers should be calling
Robert Haas robertmh...@gmail.com writes:
On Thu, Apr 30, 2015 at 5:21 PM, Kouhei Kaigai kai...@ak.jp.nec.com wrote:
I wanted to submit the v14 after the above items get clarified.
The attached patch (v14) includes all what you suggested in the previous
message.
Committed, after
On Sun, Apr 26, 2015 at 10:00 PM, Kouhei Kaigai kai...@ak.jp.nec.com wrote:
The attached patch v13 is revised one according to the suggestion
by Robert.
Thanks.
The last hunk in foreign.c is a useless whitespace change.
Sorry, my oversight.
+ /* actually, not shift members
On Thu, Apr 30, 2015 at 9:16 AM, Kouhei Kaigai kai...@ak.jp.nec.com wrote:
It seems to me the code block for T_ForeignScan and T_CustomScan in
setrefs.c are a bit large. It may be better to have a separate
function like T_IndexOnlyScan.
How about your opinion?
Either way is OK with me
201 - 300 of 443 matches
Mail list logo
