> , On Wed, Aug 26, 2015 at 4:05 AM, Kouhei Kaigai 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 columnar-stores?
> >
> > 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 under
> 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
> 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
> >>> reche
> -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 Z
ERS] Our trial to TPC-DS but optimizer made unreasonable
> plan
>
> On Mon, Aug 17, 2015 at 6:40 AM, Kouhei Kaigai wrote:
> > I think SortSupport logic provides a reasonable way to solve this
> > kind of problem. For example, btint4sortsupport() informs a function
>
> On 2015-08-26 00:55:48 +0000, 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 a
> On 2015/08/26 17:05, Kouhei 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 d
> 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 cann
> > 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.
> > I
> 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 cal
> On 2015-08-25 14:42:32 -0400, Tom Lane wrote:
> > Andres Freund 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, which'd
tgresql.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,
>
> On Fri, Aug 21, 2015 at 7:40 PM, Robert Haas wrote:
> >
> > On Tue, Aug 18, 2015 at 11:27 PM, Amit Kapila
> > 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 (like
> > >> PARALLEL_KEY_SCAN
> 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 al
> 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 ab
> On Mon, Aug 17, 2015 at 9:40 AM, Kouhei Kaigai 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
&
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 supp
> On Mon, Aug 17, 2015 at 6:40 AM, Kouhei Kaigai 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 a
ion failed
> with
> crazy number of rows
>
> On 19 August 2015 at 08:54, Kevin Grittner wrote:
>
>
> Kouhei Kaigai wrote:
>
> > longlbuckets;
>
> > lbuckets = 1 << my_log2(hash_table_bytes / bucket_size);
>
> Kouhei Kaigai 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
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 ExceptionalC
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 joi
-
NEC Business Creation Division / PG-Strom Project
KaiGai Kohei
> -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: Postg
> On Fri, Aug 7, 2015 at 2:15 PM, Kouhei Kaigai wrote:
> >
> > > On Sat, Aug 1, 2015 at 6:39 PM, Kouhei Kaigai
> > > wrote:
> > > >
> >
> > > > > > If we pull Funnel here, I think the plan shall be as f
> On Thu, Aug 13, 2015 at 2:49 AM, Kouhei Kaigai 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 L
(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 exa
[mailto:pgsql-hackers-ow...@postgresql.org] On Behalf Of Etsuro Fujita
> > Sent: Wednesday, August 12, 2015 8:26 PM
> > To: Robert Haas; Kaigai Kouhei(海外 浩平)
> > Cc: PostgreSQL-development; 花田茂
> > Subject: Re: [HACKERS] Foreign join pushdown vs EvalPlanQual
> >
>
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 wrote:
> >>> I could have a discussion with Fujita-san about this topic.
> >>>
> >> Also, let me share with the
> On Sat, Aug 1, 2015 at 6:39 PM, Kouhei Kaigai wrote:
> >
> > > On Tue, Jul 28, 2015 at 6:08 PM, Kouhei Kaigai
> > > wrote:
> > >
> > > I am not sure, but what problem do you see in putting Funnel node
> > > for one of the relation scans
needs enhancement of FDW APIs.
I'd like to see people's comment.
--
NEC Business Creation Division / PG-Strom Project
KaiGai Kohei
> -Original Message-
> From: pgsql-hackers-ow...@postgresql.org
> [mailto:pgsql-hackers-ow...@postgresql.org] On Behalf Of Kouhei Kaigai
&
> 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, Custo
ailto: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; Haribab
> On Fri, Jul 3, 2015 at 6:25 AM, Etsuro Fujita
> 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 could see how to mak
> On Tue, Jul 28, 2015 at 6:08 PM, Kouhei Kaigai wrote:
> >
> > > On Tue, Jul 28, 2015 at 7:59 AM, Kouhei Kaigai
> > > wrote:
> > > >
> > > > > -Original Message-
> > > > > From: pgsql-hackers-ow...@postgresql.org
>
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
pgsql-v9.5-fix-copy-custom-scan.patch
Description: pgsql-v9.5-fix-copy-custom-scan.patch
--
Sent via pg
> On Wed, Jul 29, 2015 at 7:32 PM, Kouhei Kaigai 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 Par
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 a
> 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 di
> On 27 July 2015 at 21:09, Kyotaro HORIGUCHI
> 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
> ParallelAppend(SeqScan). What difference is
> 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)
> On Tue, Jul 28, 2015 at 7:59 AM, Kouhei Kaigai wrote:
> >
> > > -Original Message-
> > > From: pgsql-hackers-ow...@postgresql.org
> > > [mailto:pgsql-hackers-ow...@postgresql.org] On Behalf Of Kouhei Kaigai
> > > Sent: Monday,
uly 27, 2015 8:42 AM
> To: 'Tom Lane'
> Cc: pgsql-hackers@postgresql.org
> Subject: RE: [HACKERS] CustomScan and readfuncs.c
>
> > Kouhei Kaigai writes:
> > > Under the investigation of ParallelAppend, I noticed here is a few
> > > problems in CustomScan, t
> -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
>
> On Sun, Jul 26, 2015 at 8:43 AM, Kouhei Kaigai wrote:
> >
> > Hello,
> >
> > I'm recently working/investigating on ParallelAppend feature
> > towards the next commit fest. Below is my design proposal.
> >
> > 1. Concept
> > --
>
> 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
f
> 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.
> >>
> On 04/01/2015 06:28 PM, Robert Haas wrote:
> > On Mon, Mar 30, 2015 at 1:28 AM, Michael Paquier
> > 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, aggregat
> Kouhei Kaigai 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. CustomScanMetho
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
T
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 par
ns
> breaks
> EPQ testing, doesn't it?
>
> On Thu, Jul 23, 2015 at 8:27 PM, Kouhei Kaigai wrote:
> > A dark side is, as discussed in this thread, complexity of EvalPlanQual.
> > RefetchForeignRow() returns a tuple based on foreign table definition,
> > on t
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 testi
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
> > > anot
> On Wed, Jul 22, 2015 at 8:24 PM, Kouhei Kaigai 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??
&
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 src/backend/access/c
> > 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 woul
> -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-Str
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
>
:
>
Subject: Re: [HACKERS] fdw_scan_tlist for foreign table scans breaks EPQ
> testing,
> doesn't it?
>
> On Wed, Jul 22, 2015 at 8:13 AM, Kouhei Kaigai wrote:
> >> No, what I'm concerned about is the case when scanrelid > 0.
> >>
> > Hmm. if scanrelid > 0,
testing,
> doesn't it?
>
> Hi KaiGai-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 a
> -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] Asyn
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 th
tidscan as an example of custom-scan (Re: [HACKERS] [v9.5]
> Custom
> Plan API)
>
> On Wed, Jul 15, 2015 at 10:12 AM, Kouhei Kaigai wrote:
> > We never guarantee the interface compatibility between major version up.
> > If we add/modify interface on v9.6, it is duty for
> 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 modu
> 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,
> 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
>
> -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 custo
> > 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
> 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 re
> > 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, mo
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 t
ple of custom-scan (Re: [HACKERS] [v9.5]
> Custom
> Plan API)
>
>
>
> On Tue, Jan 6, 2015 at 10:51 PM, Kouhei Kaigai wrote:
>
>
> Jim, Thanks for your reviewing the patch.
>
> The attached patch is revised one according to your suggestion,
>
> > 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-ow...@postgresql.org
> [mailto:pgsql-hackers-ow...@postgresql.org] On Behalf Of Etsuro Fujita
> Sent: Thursday, June 25, 2015 3:12 PM
> To: Kaigai Kouhei(海外 浩平)
> Cc: PostgreSQL-development
> Subject: Re: [HACKERS] Foreign join pushdown vs EvalPlanQual
>
> Hi KaiGa
> On Thu, Jun 25, 2015 at 11:55 PM, Robert Haas wrote:
> > On Thu, Jun 25, 2015 at 6:25 PM, Kouhei Kaigai wrote:
> >> I have a serious open item reported 1.5 month ago then reminded
> >> several times has not been fixed up yet.
> >>
> &
> -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
Subject: Re: [HACKERS] upper planner path-ification
>
> On Tue, Jun 23, 2015 at 4:41 AM, Kouhei Kaigai 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 ab
t; On 23 June 2015 at 13:55, Kouhei Kaigai wrote:
>
>
> Once we support to add aggregation path during path consideration,
> we need to pay attention morphing of the final target-list according
> to the intermediate path combination, tentatively chosen.
>
> -Original Message-
> From: pgsql-hackers-ow...@postgresql.org
> [mailto:pgsql-hackers-ow...@postgresql.org] On Behalf Of Tom Lane
> Sent: Monday, May 18, 2015 1:12 AM
> To: Robert Haas
> Cc: pgsql-hackers@postgresql.org
> Subject: Re: [HACKERS] upper planner path-ification
>
> Robert Haa
> -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 be
> 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
> Robert Haas 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.
>
> [ sorry for
PM
> 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 wrote:
> > Hello,
> >
> > I got the following error during DBT-3 benchmark with SF=20.
> >
&
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
t
> 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 ...
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 m
> On Thu, Jun 4, 2015 at 9:40 PM, Kouhei Kaigai 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
> On Sat, May 30, 2015 at 9:03 PM, Kouhei Kaigai 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
> > m
> -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
>
Hi,
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/effective.
Let me share it with pgsql-hackers.
He said, we may have a workload t
> -Original Message-
> Sent: Friday, May 15, 2015 8:44 AM
> To: 'Tom Lane'; Kohei KaiGai
> Cc: Robert Haas; Thom Brown; Shigeru Hanada; pgsql-hackers@postgreSQL.org
> Subject: RE: Custom/Foreign-Join-APIs (Re: [HACKERS] [v9.5] Custom Plan API)
>
> > A possible compromise that we could perh
> > One thing tricky is "peusdo projection" which is done by
> > deparseProjectionSql for whole-row reference. This is done by put the
> > query string in FROM subquery and add whole-row reference in outer
> > SELECT clause. This is done by ExecProjection in 9.4 and older, but
> > we need to do t
> Just so we're all in the same page, there are some further open items
> (both addressed and not yet addressed) in the usual Wiki page,
> https://wiki.postgresql.org/wiki/Open_Items
>
I added the problem around foreign/custom-join still not resolved.
Thanks,
--
NEC Business Creation Division / PG
needs to be merged to solve the problem.
Thanks,
--
NEC Business Creation Division / PG-Strom Project
KaiGai Kohei
> -Original Message-
> From: pgsql-hackers-ow...@postgresql.org
> [mailto:pgsql-hackers-ow...@postgresql.org] On Behalf Of Kouhei Kaigai
> Sent: Friday, May 15, 20
> 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 thi
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 non-st
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,
201 - 300 of 457 matches
Mail list logo
