PGConf.ASIA2017 Developer Unconference
An Unconference-style event for active PostgreSQL developers will be held on 4 Dec, 2017 at Akihabara Conference Center, as part of PGConf.ASIA 2017.
This Unconference will be focused on technical PostgreSQL development discussions ranging from Clustering and replication to the infrastructure.
Unconference Tokyo Round Time Table
| Time | Room 1 | Room 2 |
|---|---|---|
| 9:00-10:00 | Registration and theme proposal | |
| 10:00-10:30 | Arrangement & theme decision | |
| 10:30-11:20 | GPU Acceleration | Diagrams and pictures in the docs |
| 11:30-12:20 | SCRAM improvements | Upgrading without downtime |
| 12:20-13:30 | Lunch | Lunch |
| 13:30-14:20 | Asian community affairs | Mailing list enhancements |
| 14:30-15:20 | NoSQL in Postgres | Sharding |
| 15:20-15:40 | Coffee | Coffee |
| 15:40-16:30 | Logical replication | Partitioning |
| 16:30-17:00 | Group photo |
Unconference minutes
GPU Acceleration
Coordinator: KaiGai Kohei
KaiGai introduced the recent updates of GPU acceleration on PostgreSQL; especially, two major features. The first one is SSD-to-GPU Direct SQL Execution for I/O heavy workloads. The other one is PL/CUDA for calculation intensive workloads.
SSD-to-GPU Direct SQL Execution utilizes P2P DMA from SSD to GPU, then GPU processes the pre-compiled SQL workloads to reduce amount of the records processed by CPU. It eventually looks like I/O acceleration by cooperation of SSD/GPU. As a future improvement, he mention about columnar-cache (in v2.0) and intelligent storage concept (v3.0). The columnar-cache constructs in-memory cache with conversion to the columnar-format. GPU kernel can switch its kernel according to existence of the cache.
One question from the audience was integration with the pluggable storage project in PostgreSQL. It has both of advantage and disadvantage. The columnar-store is persistent entity, so it has to involve storage write on updates, on the other hands, no need to convert the storage format if storage layer already has raw data in columnar format. KaiGai is positive to support columnar-storage also, once PostgreSQL core support a columnar storage engine.
Intelligent Storage is a concept to utilize special SSD products that allow to mount custom logic on storage side. Once we could implement a logic to convert row-data of PostgreSQL to columnar format prior to send packet over PCIe, it can reduce the PCIe bandwidth consumption and can pull out maximum performance of GPU.
One other discussion from the audience was enhancement of interfaces. Now PostgreSQL has well designed custom-scan interface; that allows to generate GPU programs and compile it on the fly, then callbacks on executor allows extension to switch optimal way to scan the source tables. If tablespace is constructed on NVMe-SSD and table-size is enough larger than physical RAM, PG-Strom switches SSD2GPU direct instead of the normal buffered read. Once intelligent storage mechanism got supported, a new alternative option will be added.
Diagrams and pictures in the docs
Problem: For 20 years we do not have any diagrams and schemes (D&S) in documentation, which doesn't help users to understand docs
History of the question was briefly discussed:
- Long time the main obstacle was sgml format of the documentation, now with switching to xml this problem is gone
- Many hackers want to see D&S in a diff-aware format to keep it under version control almost like code. After initial discussion, this approach considered as unrealistic and agreed, that to have useful D&S for users is more important than to not have them because that is inconvenient for hackers. Diff in a form of picture-before and picture-after looks sufficient for review.
Suggestions:
- Evaluate some vector format, pretty mush everyone suggested svg as it meet requirements to be supported by all browsers and to be easy to create in many editors.
- If necessary, elaborate some standard (expand and improve it if necessary), like limited colors, types of lines etc
- Try to submit to normal CF some D&S to try to put them through review
SCRAM improvements
Coordinator: Michael Paquier
A short introduction about SCRAM authentication and channel binding features has first been done. Then the discussion was focused on what could be improved within the existing infrastructure.
First, addition of a connection parameter to enforce the client to fail if a rogue server is attempting to downgrade to MD5 a server which wants to use SCRAM. This can be a feature interesting after an upgrade to prevent MD5 from being used anymore and that the client always expects SCRAM. Out of that, the security gain may not be worth it: even when using channel binding, using SSL CAs can still be needed as channel binding just prevents MITM. If a client connects to an incorrect server and does the SSL negotiation with an attacker from the start when the channel binding does not serve much.
Second, the addition of an option at hba-level which allows server to reject connections not willing to use channel binding. This has been seen as people also having a limited impact which may not be worth the complication of the code it introduces. Being able to control channel binding from the client-side is more interesting.
More description about upgrade issues from MD5 and SCRAM has happened as well as questions on the matter.
Upgrading without downtime
Lunch
Asian community affairs
Coordinator: Hemmi
Introduction of local communities: Indonesia, India, South Korea, Philippines, Vietnam, Taiwan, Japan
Indonesia: How did it start at Indonesia? Began from training session, not enterprise origin more than 10 years before.
India: Very strong community base. PGconf.India expects 200-300 participants. EDB pays much efforts to promote PostgreSQL in India. Some India folks have contributed core features like FDW, partitioning and so on.
South Korea: Facebook group in South Korea is one of the most active community, like technical documentation translation. How open source accepted in enterprise of South Korea? Usually OracleDB, but a startup back adopted MySQL 5 years before.
Philippines: Little active community, however, some companies offer training services in enterprise class. SMB or academic mainly uses open source for cost reduction. (Here is a case of PostgreSQL at small telecommunications and banking customers.)
Vietnam: Academic user is majority of user base. (presenter's point of view) User community was launched at Jul-2017, with 10 members. The first meetup was held. They want to provide .po files for Vietnam language.
Taiwan:
Japan: Two major community for PostgreSQL. JPUG; grass roots users group more than 15years. PGEcons; a consortium supported by enterprises. Which is majority users? Academic/Education or Enterprise? Likely, enterprise users is majority. Japan has large user base. (Likely, Russian user has grown rapidly.) What is a good idea to promote PostgreSQL in other nations also. Education and certification of professional are significant; OSS-DB program by LPI Japan. No certification cannot cover all type of the skill-set.
Mailing list enhancements
Problem: More and more people prefer forums over mailing lists.
After some initial discussion, it's noted that the option most likely to be successful would be to make an interactive version of the archives, eg. forums.postgresql.org, based on modified archives code and PGLister.
Core requirements:
- UI - forum like, but responsive
- Ability to reply to any email through web
- Notifications on replies/watchers
- Better searching/filtering of archives
Other features:
- Search results to return threads not messages
- Highlight search terms in results
- Different notification types by email/RSS
NoSQL in Postgres
Sharding
Logical replication
Partitioning
Social Event
- All attendees can join the social event.
- Venue
* TBD
Notes
- TBD
