Re: 1 Status of vertical clustered index - 2 Join using (fk_constraint) suggestion - 3 Status of pgsql's parser autonomization

From: Imre Samu <pella(dot)samu(at)gmail(dot)com>
To: maxzor <maxzor(at)maxzor(dot)eu>
Cc: "pgsql-generallists(dot)postgresql(dot)org" <pgsql-general(at)lists(dot)postgresql(dot)org>
Subject: Re: 1 Status of vertical clustered index - 2 Join using (fk_constraint) suggestion - 3 Status of pgsql's parser autonomization
Date: 2020-02-17 02:16:42
Message-ID: CAJnEWwngQw8B0yK2drn0hE-n6OJNzaLh53_MJw849WuHkJmJOA@mail.gmail.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-general pgsql-hackers

> 3. What is the status of making the internal parser of PostgreSQL less
coupled to the core, and easier to cherry-pick from outside?

imho:
One of the current solutions is: https://github.com/lfittl/libpg_query C
library

"C library for accessing the PostgreSQL parser outside of the server.

This library uses the actual PostgreSQL server source to parse SQL queries
and return the internal PostgreSQL parse tree.Note that this is mostly
intended as a base library for

- pg_query <https://github.com/lfittl/pg_query> (Ruby),

- pg_query.go <https://github.com/lfittl/pg_query.go> (Go),

- pg-query-parser <https://github.com/zhm/pg-query-parser> (Node),

- psqlparse <https://github.com/alculquicondor/psqlparse> (Python) and

- pglast <https://pypi.org/project/pglast/> (Python 3)."

"

Best,
Imre

maxzor <maxzor(at)maxzor(dot)eu> ezt írta (időpont: 2020. febr. 16., V, 22:38):

> Hello,
>
> 1. I was told that M$ SQLServer provides huge performance deltas over
> PostgreSQL when dealing with index-unaligned queries :
> create index i on t (a,b, c);
> select * from t where b=... and c=...;
> Columnar storage has been tried by various companies, CitusData,
> EnterpriseDB, 2ndQuadrant, Fujitsu Enterprise Postgres. It has been
> discussed quite a lot, last thread that I was able to find being in 2017,
> https://www.postgresql.org/message-id/CAJrrPGfaC7WC9NK6PTTy6YN-NN%2BhCy8xOLAh2doYhVg5d6HsAA%40mail.gmail.com
> where Fujitsu's patch made it quite far.
> What is the status on such a storage manager extension interface ?
>
> 2. What do you think of adding a new syntax : 'from t join t2 using
> (fk_constraint)' ? And further graph algorithms to make automatic joins ?
> Both 'natural join' and 'using (column_name)' are useless when the
> columns are not the same in source and destination.
> Plus it is often the case that the fk_constraints are over numerous
> columns, even though this is usually advised against. But when this case
> happens there will be a significant writing speedup.
> I have been bothered by this to the point that I developed a
> graphical-query-builder plugin for pgModeler,
>
> https://github.com/maxzor/plugins/tree/master/graphicalquerybuilder#automatic-join-mode
> ,
> but I believe such a syntax would be much better in the core!
>
> 3. What is the status of making the internal parser of PostgreSQL less
> coupled to the core, and easier to cherry-pick from outside?
> It would be great to incorporate it into companion projects : pgAdmin4,
> pgModeler, pgFormatter...
>
> BR, Maxime Chambonnet
>

In response to

Browse pgsql-general by date

  From Date Subject
Next Message Loai Abdallatif 2020-02-17 09:50:01 Postgres error
Previous Message maxzor 2020-02-17 01:56:52 Re: 1 Status of vertical clustered index - 2 Join using (fk_constraint) suggestion - 3 Status of pgsql's parser autonomization

Browse pgsql-hackers by date

  From Date Subject
Next Message Tatsuo Ishii 2020-02-17 02:37:10 Re: Conflict handling for COPY FROM
Previous Message Moon, Insung 2020-02-17 02:04:47 Flexible pglz_stategy values and delete const.