My environment is : 1 master 3 segments
SQL >>:
CREATE TABLE call_center (
cc_call_center_sk integer,
cc_call_center_id character varying(16),
cc_rec_start_date date,
cc_rec_end_date date,
cc_closed_date_sk integer,
cc_open_date_sk integer,
cc_name character
FYI: the two issues related to the Perl Artistic License have been resolved
in both 2.0.0.0-incubating and master branches:
Remove ASF Category X incompatible JSON Perl Module (Artistic license)
https://issues.apache.org/jira/browse/HAWQ-1062
Declare PL/Perl's ppport.h source file to be an Artist
Just to confirm based on Legal-79, ppport.h is an exception with your PR,
it looks we're good now.
Thanks Ed.
-Goden
On Wed, Sep 21, 2016 at 1:52 AM Ed Espino wrote:
> FYI: the two issues related to the Perl Artistic License have been resolved
> in both 2.0.0.0-incubating and master branches:
>
Your default_hash_table_bucket_number value is set to 6. Typically, this
should be adjusted as 6 x #_of_your_segment_hosts. With 3 segments, you
should set this value to 18. Any time you change this parameter, you should
redistribute your HASH distributed tables, if you have any (unless the
table D
What have we decided here? Fold libhdfs3 back into HAWQ for the near term
and revisit spinning it out in a dedicated submodule / repo down the road?
Do we need to have a consensus vote for this action?
As for the outstanding PRs and issues in the current repo, who will be
moving those to HAWQ? Are
On Wed, Sep 21, 2016 at 10:08 AM, Kyle Dunn wrote:
> What have we decided here? Fold libhdfs3 back into HAWQ for the near term
> and revisit spinning it out in a dedicated submodule / repo down the road?
To me this sounds like a near term decision. IOW, the other repo is clearly
read/only at this
Also on your location clause you should not reference the same file more
than one time.
If you want to scale gpfdist process you need to use different range on
each port for a same server. (Not sure if I explain myself :))
If you use one gpfdist per server performance should be fine. One gpfdist
> Personally, I suggest that whoever was managing the library in a separate repo
on GH (and it sounds like Zhanwei Wang is that person) pings the submitters
of all the oustanding PRs (via comment on the PR) telling them to resubmit
via HAWQ's JIRA.
I 100% disagree with this. As a gesture of apprec
Kyle R Dunn created HAWQ-1066:
-
Summary: Improper handling of install name for shared library on
OS X
Key: HAWQ-1066
URL: https://issues.apache.org/jira/browse/HAWQ-1066
Project: Apache HAWQ
Iss
Radar Lei created HAWQ-1067:
---
Summary: Append hawq version number to plr-hawq rpm pakcage name
Key: HAWQ-1067
URL: https://issues.apache.org/jira/browse/HAWQ-1067
Project: Apache HAWQ
Issue Type: T
10 matches
Mail list logo