Thread: Re: [HACKERS] On How To Shorten the Steep Learning Curve Towards PG Hacking...

On 27 March 2017 at 13:00, Kang Yuzhe <tiggreen87@gmail.com> wrote:

> I have found PG source Code reading and hacking to be one the most
> frustrating experiences in my life.  I believe that PG hacking should not be
> a painful journey but an enjoyable one!
>
> It is my strong believe that out of my PG hacking frustrations, there may
> come insights for the PG experts on ways how to devise hands-on with PG
> internals so that new comers will be great coders as quickly as possible.

I'm here now because PostgreSQL has clear, well designed and
maintained code with accurate docs, great comments and a helpful team.

I'd love to see detailed cases where another project is better in a
measurable way; I am willing to learn from that.

Any journey to expertise takes 10,000 hours. There is no way to shorten that.

What aspect of your journey caused you pain?

-- 
Simon Riggs                http://www.2ndQuadrant.com/
PostgreSQL Development, 24x7 Support, Remote DBA, Training & Services



Thanks Simon for taking your time and trying to tell and warn me the harsh reality truth:there is no shortcut to expertise. One has to fail and rise towards any journey to expertise.
Overall, you are right. But I do believe that there is a way(some techniques) to speed up any journey to expertise. One of them is mentorship. For example(just an example), If you show me how to design and implement FDW to Hadoop/HBase., I believe that I will manage to design and implement FDW to Cassandra/MengoDB.

The paths towards any journey to expertise by working alone/the hard way and working with you using as a mentorship are completely different. I believe that we humans have to power to imitate and get innovative afterwords.

There are many books on PG business application development:
1. PostgreSQL Essential Reference/Barry Stinson
2.
PostgreSQL : introduction and concepts / Momjian,
Bruce.
3. PostgreSQL Cookbook/Over 90 hands-on recipes to effectively manage,
administer, and design solutions using PostgreSQL
4.PostgreSQL Developer's Handbook
5.PostgreSQL 9.0 High Performance
6.PostgreSQL Server Programming
7.PostgreSQL for Data Architects/Discover how to design, develop, and maintain your
database application effectively with PostgreSQL
8.Practical PostgreSQL
9.Practical SQL Handbook, The: Using SQL Variants, Fourth Edition
10.PostgreSQL: The comprehensive guide to building, programming, and administering PostgreSQL databases, Second Edition
11.Beginning Databases with PostgreSQL From Novice to Professional, Second Edition
12.PostgreSQL Succinctly
13.
PostgreSQL Up and Running
....

But almost nothing about The Internals of PostgreSQL:
1. The Internals of PostgreSQL:
http://www.interdb.jp/pg/index.html  translated from Japanese Book
2. PostgreSQL数据库内核分析(Chinese) Book on t
he Internals of PostgreSQL:
3. PG Docs/site
4. some here and there which are less useful

Lastly, I have come to understand that PG community is not harsh/intimidating to newbies and thus, I am feeling at home.

Regards,
Zeray

On Mon, Apr 17, 2017 at 7:33 PM, Simon Riggs <simon@2ndquadrant.com> wrote:
On 27 March 2017 at 13:00, Kang Yuzhe <tiggreen87@gmail.com> wrote:

> I have found PG source Code reading and hacking to be one the most
> frustrating experiences in my life.  I believe that PG hacking should not be
> a painful journey but an enjoyable one!
>
> It is my strong believe that out of my PG hacking frustrations, there may
> come insights for the PG experts on ways how to devise hands-on with PG
> internals so that new comers will be great coders as quickly as possible.

I'm here now because PostgreSQL has clear, well designed and
maintained code with accurate docs, great comments and a helpful team.

I'd love to see detailed cases where another project is better in a
measurable way; I am willing to learn from that.

Any journey to expertise takes 10,000 hours. There is no way to shorten that.

What aspect of your journey caused you pain?

--
Simon Riggs                http://www.2ndQuadrant.com/
PostgreSQL Development, 24x7 Support, Remote DBA, Training & Services

On 18 April 2017 at 15:41, Kang Yuzhe <tiggreen87@gmail.com> wrote:
> Thanks Simon for taking your time and trying to tell and warn me the harsh
> reality truth:there is no shortcut to expertise. One has to fail and rise
> towards any journey to expertise.

Yeah, just because Pg is hard doesn't mean it's notably bad or worse
than other things. I generally find working on code in other projects,
even smaller and simpler ones, a rather unpleasant change.

That doesn't mean we can't do things to help interested new people get
and stay engaged and grow into productive devs to grow our pool.

> Overall, you are right. But I do believe that there is a way(some
> techniques) to speed up any journey to expertise. One of them is mentorship.
> For example(just an example), If you show me how to design and implement FDW
> to Hadoop/HBase., I believe that I will manage to design and implement FDW
> to Cassandra/MengoDB.

TBH, that's the sort of thing where looking at existing examples is
often the best way forward and will stay that way.

What I'd like to do is make it easier to understand those examples by
providing background and overview info on subsystems, so you can read
the code and have more idea what it does and why.

> But almost nothing about The Internals of PostgreSQL:

Not surprising. They'd go out of date fast, be a huge effort to write
and maintain, and sell poorly given the small audience.

Print books probably aren't the way forward here.

-- Craig Ringer                   http://www.2ndQuadrant.com/PostgreSQL Development, 24x7 Support, Training & Services



Thanks Craig for teaching me a lot of things. I am just learning a lot why PG hacking/development is the way it is.

Regarding interest and enthusiasm, no problem. Whats is lacking is the skill-sets and I believe having interest and enthusiasm and with your support, we will expand PG hacking/devs/usage in Africa and other continents.

People here in Africa using Oracle/SQL Server/IBM products(generally commercial products) even for which PG is more than enough.

I want to change this scenario and trend and I hope one day in the future there will be PG conference in Africa/Ethiopia which is my country.

Thanks,
zeray




On Tue, Apr 18, 2017 at 10:54 AM, Craig Ringer <craig@2ndquadrant.com> wrote:
On 18 April 2017 at 15:41, Kang Yuzhe <tiggreen87@gmail.com> wrote:
> Thanks Simon for taking your time and trying to tell and warn me the harsh
> reality truth:there is no shortcut to expertise. One has to fail and rise
> towards any journey to expertise.

Yeah, just because Pg is hard doesn't mean it's notably bad or worse
than other things. I generally find working on code in other projects,
even smaller and simpler ones, a rather unpleasant change.

That doesn't mean we can't do things to help interested new people get
and stay engaged and grow into productive devs to grow our pool.

> Overall, you are right. But I do believe that there is a way(some
> techniques) to speed up any journey to expertise. One of them is mentorship.
> For example(just an example), If you show me how to design and implement FDW
> to Hadoop/HBase., I believe that I will manage to design and implement FDW
> to Cassandra/MengoDB.

TBH, that's the sort of thing where looking at existing examples is
often the best way forward and will stay that way.

What I'd like to do is make it easier to understand those examples by
providing background and overview info on subsystems, so you can read
the code and have more idea what it does and why.

> But almost nothing about The Internals of PostgreSQL:

Not surprising. They'd go out of date fast, be a huge effort to write
and maintain, and sell poorly given the small audience.

Print books probably aren't the way forward here.

--
 Craig Ringer                   http://www.2ndQuadrant.com/
 PostgreSQL Development, 24x7 Support, Training & Services

Re: [HACKERS] On How To Shorten the Steep Learning Curve Towards PGHacking...

From
Andrew Dunstan
Date:

On 04/18/2017 03:41 AM, Kang Yuzhe wrote:
>
>
> But almost nothing about The Internals of PostgreSQL:
> 1. The Internals of PostgreSQL:
> http://www.interdb.jp/pg/index.html  translated from Japanese Book
> 2. PostgreSQL数据库内核分析(Chinese) Book on the Internals of PostgreSQL:
> 3. PG Docs/site
> 4. some here and there which are less useful
>



I agree that this is an area where more material would be very welcome,
and not only to newcomers. #1 is useful as far as it goes, but the
missing bits (esp. Query Processing) are critical.



> Lastly, I have come to understand that PG community is not
> harsh/intimidating to newbies and thus, I am feeling at home.
>
>


Glad you have found it so.

cheers

andrew

-- 
Andrew Dunstan                https://www.2ndQuadrant.com
PostgreSQL Development, 24x7 Support, Remote DBA, Training & Services




Re: [HACKERS] On How To Shorten the Steep Learning Curve Towards PGHacking...

From
Andrew Dunstan
Date:

On 04/18/2017 03:54 AM, Craig Ringer wrote:
>> But almost nothing about The Internals of PostgreSQL:
> Not surprising. They'd go out of date fast, be a huge effort to write
> and maintain, and sell poorly given the small audience.
>
> Print books probably aren't the way forward here.
>


Agreed,  a well organized web site would work much better.

cheers

andrew

-- 
Andrew Dunstan                https://www.2ndQuadrant.com
PostgreSQL Development, 24x7 Support, Remote DBA, Training & Services




Re: [HACKERS] On How To Shorten the Steep Learning Curve Towards PGHacking...

From
"Finnerty, Jim"
Date:

I’ve seen the inside of quite a few commercial database products, and imho PostgreSQL’s code is cleaner and better-organized than all but one of them.  That one retained PostgreSQL for parsing and semantic analysis, but replaced the optimizer, execution engine, and storage layer in C++.

 

…and as far as the interest and enthusiasm of the PG community, I’ve never seen anything like it.  My only complaint is that pgsql-hackers keeps blowing out my Outlook file size limit.  :^)

 

From: <pgsql-hackers-owner@postgresql.org> on behalf of Kang Yuzhe <tiggreen87@gmail.com>
Date: Tuesday, April 18, 2017 at 4:33 AM
To: Craig Ringer <craig@2ndquadrant.com>
Cc: Simon Riggs <simon@2ndquadrant.com>, PostgreSQL-development <pgsql-hackers@postgresql.org>
Subject: Re: [HACKERS] On How To Shorten the Steep Learning Curve Towards PG Hacking...

 

Thanks Craig for teaching me a lot of things. I am just learning a lot why PG hacking/development is the way it is.

Regarding interest and enthusiasm, no problem. Whats is lacking is the skill-sets and I believe having interest and enthusiasm and with your support, we will expand PG hacking/devs/usage in Africa and other continents.

People here in Africa using Oracle/SQL Server/IBM products(generally commercial products) even for which PG is more than enough.

I want to change this scenario and trend and I hope one day in the future there will be PG conference in Africa/Ethiopia which is my country.

Thanks,

zeray

 

 

 

On Tue, Apr 18, 2017 at 10:54 AM, Craig Ringer <craig@2ndquadrant.com> wrote:

On 18 April 2017 at 15:41, Kang Yuzhe <tiggreen87@gmail.com> wrote:
> Thanks Simon for taking your time and trying to tell and warn me the harsh
> reality truth:there is no shortcut to expertise. One has to fail and rise
> towards any journey to expertise.

Yeah, just because Pg is hard doesn't mean it's notably bad or worse
than other things. I generally find working on code in other projects,
even smaller and simpler ones, a rather unpleasant change.

That doesn't mean we can't do things to help interested new people get
and stay engaged and grow into productive devs to grow our pool.

> Overall, you are right. But I do believe that there is a way(some
> techniques) to speed up any journey to expertise. One of them is mentorship.
> For example(just an example), If you show me how to design and implement FDW
> to Hadoop/HBase., I believe that I will manage to design and implement FDW
> to Cassandra/MengoDB.

TBH, that's the sort of thing where looking at existing examples is
often the best way forward and will stay that way.

What I'd like to do is make it easier to understand those examples by
providing background and overview info on subsystems, so you can read
the code and have more idea what it does and why.

> But almost nothing about The Internals of PostgreSQL:

Not surprising. They'd go out of date fast, be a huge effort to write
and maintain, and sell poorly given the small audience.

Print books probably aren't the way forward here.

--
 Craig Ringer                   http://www.2ndQuadrant.com/
 PostgreSQL Development, 24x7 Support, Training & Services

 

Hello Simon,
The journey that caused and is causing me a lot of pain is finding my way in PG development.
Complex Code Reading like PG. Fully understanding the science of DBMS Engines: Query Processing, Storage stuff, Transaction Management and so  on...

Anyway as you said, the rough estimation towards any expertise seems to be in abidance with by The 10,000 Hour Rule. I will strive based on this rule.

For now, would please tell me how to know the exact PG version to which a specific patch was developed?
Given x patch, how do I know the specific PG version it was developed for?

Regards,
Zeray



On Mon, Apr 17, 2017 at 7:33 PM, Simon Riggs <simon@2ndquadrant.com> wrote:
On 27 March 2017 at 13:00, Kang Yuzhe <tiggreen87@gmail.com> wrote:

> I have found PG source Code reading and hacking to be one the most
> frustrating experiences in my life.  I believe that PG hacking should not be
> a painful journey but an enjoyable one!
>
> It is my strong believe that out of my PG hacking frustrations, there may
> come insights for the PG experts on ways how to devise hands-on with PG
> internals so that new comers will be great coders as quickly as possible.

I'm here now because PostgreSQL has clear, well designed and
maintained code with accurate docs, great comments and a helpful team.

I'd love to see detailed cases where another project is better in a
measurable way; I am willing to learn from that.

Any journey to expertise takes 10,000 hours. There is no way to shorten that.

What aspect of your journey caused you pain?

--
Simon Riggs                http://www.2ndQuadrant.com/
PostgreSQL Development, 24x7 Support, Remote DBA, Training & Services



On 28 Apr. 2017 17:04, "Kang Yuzhe" <tiggreen87@gmail.com> wrote:
Hello Simon,
The journey that caused and is causing me a lot of pain is finding my way in PG development.
Complex Code Reading like PG. Fully understanding the science of DBMS Engines: Query Processing, Storage stuff, Transaction Management and so  on...

Anyway as you said, the rough estimation towards any expertise seems to be in abidance with by The 10,000 Hour Rule. I will strive based on this rule.

Start with not top-posting on the mailing list ;)


For now, would please tell me how to know the exact PG version to which a specific patch was developed?
Given x patch, how do I know the specific PG version it was developed for?

If it a was created by git format-patch then the base git revision will be shown. This may be a commit from postgres public tree that you can find with 'git branch --contains'.

Otherwise look at the proposed commit message if any, in the patch header. Or the email it was attached to. If all else fails guess based on the date.