Re: [HACKERS] Multi-column distinctness.

On 19 October 2015 at 20:16, Tomas Vondra wrote: > Hello Kyotaro-san, > > On 09/11/2015 06:58 PM, Tomas Vondra wrote: > > > >> Maybe the best solution is to abandon the ALTER TABLE approach >> entirely, and instead invent a new set of commands >> >>CREATE

Re: [HACKERS] Multi-column distinctness.

On 10/20/2015 05:59 PM, Tom Lane wrote: Robert Haas writes: On Tue, Oct 20, 2015 at 10:51 AM, Tomas Vondra wrote: ISTM that we could use COLLECT STATISTICS instead of ADD STATISTICS, and use REMOVE STATISTICS instead of DROP STATISTICS.

Re: [HACKERS] Multi-column distinctness.

Tomas Vondra writes: > On 10/20/2015 05:59 PM, Tom Lane wrote: >> Why is this an improvement over using already-existing keywords? > The problem is that the actual syntax is ADD [COLUMN], so we can't > simply use ADD STATISTICS as that would mean a conflict in the

Re: [HACKERS] Multi-column distinctness.

On Tue, Oct 20, 2015 at 11:59 AM, Tom Lane wrote: > Robert Haas writes: >> On Tue, Oct 20, 2015 at 10:51 AM, Tomas Vondra >> wrote: > ISTM that we could use COLLECT STATISTICS instead of ADD STATISTICS, and > use

Re: [HACKERS] Multi-column distinctness.

I wrote: > Tomas Vondra writes: >> The problem is that the actual syntax is ADD [COLUMN], so we can't >> simply use ADD STATISTICS as that would mean a conflict in the grammar. >> Resolving it means either making COLUMN non-optional, or adding >> STATISTICS to

Re: [HACKERS] Multi-column distinctness.

Robert Haas writes: > On Tue, Oct 20, 2015 at 10:51 AM, Tomas Vondra > wrote: ISTM that we could use COLLECT STATISTICS instead of ADD STATISTICS, and use REMOVE STATISTICS instead of DROP STATISTICS. That way we can use ALTER

Re: [HACKERS] Multi-column distinctness.

On Tue, Oct 20, 2015 at 10:51 AM, Tomas Vondra wrote: >> Koyotaro's changes to force COLUMN to be required won't get through. >> >> ISTM that we could use COLLECT STATISTICS instead of ADD STATISTICS, and >> use REMOVE STATISTICS instead of DROP STATISTICS. That way

Re: [HACKERS] Multi-column distinctness.

On 20 October 2015 at 11:59, Tom Lane wrote: > Robert Haas writes: > > On Tue, Oct 20, 2015 at 10:51 AM, Tomas Vondra > > wrote: > ISTM that we could use COLLECT STATISTICS instead of ADD STATISTICS, > and > use

Re: [HACKERS] Multi-column distinctness.

Hi, On 10/20/2015 09:11 PM, Tom Lane wrote: I wrote: Tomas Vondra writes: The problem is that the actual syntax is ADD [COLUMN], so we can't simply use ADD STATISTICS as that would mean a conflict in the grammar. Resolving it means either making COLUMN

Re: [HACKERS] Multi-column distinctness.

On 20 October 2015 at 16:48, Tomas Vondra wrote: > and I can get this to work too >> >> | DROP STATISTICS ON '(' name_list ')' >> >> if I expand out the "DROP opt_column" productions to be two separate >> productions with and without COLUMN,

Re: [HACKERS] Multi-column distinctness.

Hi, On 10/20/2015 01:14 PM, Simon Riggs wrote: On 19 October 2015 at 20:16, Tomas Vondra > wrote: Hello Kyotaro-san, On 09/11/2015 06:58 PM, Tomas Vondra wrote: > Maybe the best solution is to abandon the

Re: [HACKERS] Multi-column distinctness.

On 10/20/2015 11:28 PM, Simon Riggs wrote: On 20 October 2015 at 16:48, Tomas Vondra > wrote: >> On 10/20/2015 09:11 PM, Tom Lane wrote: Can't we just insist that there be only one statistics declaration for a given column

Re: [HACKERS] Multi-column distinctness.

Tomas Vondra writes: > On 10/20/2015 11:28 PM, Simon Riggs wrote: >> Since this command doesn't actually ADD the statistics, it just creates >> a specification used by the next ANALYZE, it would seem better to use a >> different keyword than ADD, perhaps DECLARE

Re: [HACKERS] Multi-column distinctness.

On 20 October 2015 at 21:06, Tom Lane wrote: > I am getting more attracted to your suggestion of making these things > stand-alone commands "CREATE STATISTICS" and "DROP STATISTICS". Not only > does that fix the syntactic problems of shoehorning them into ALTER TABLE, > but

Re: [HACKERS] Multi-column distinctness.

Hello Kyotaro-san, On 09/11/2015 06:58 PM, Tomas Vondra wrote: > Maybe the best solution is to abandon the ALTER TABLE approach entirely, and instead invent a new set of commands CREATE STATISTICS DROP STATISTICS (ALTER STATISTICS seems a bit excessive at this point). Another thing is

Re: [HACKERS] Multi-column distinctness.

On 09/07/2015 05:25 AM, Kyotaro HORIGUCHI wrote: Hello, but making the COLUMN required is certainly much worse as it breaks many existing scripts. The keyword inky breaks cases that manipulate "statistics" column. Ouch! It is simply by accident, or my lack of carefulness. I will come up

Re: [HACKERS] Multi-column distinctness.

Hello, > > 5) syntax > > - > > The syntax might be one of the pain points if we eventually decide to > commit the multivariate stats patch. I have no intention in blocking this > patch for that reasons, but if we might design the syntax to make it > compatible with the multivariate patch,

Re: [HACKERS] Multi-column distinctness.

Hello, > FWIW Horiguchi-san is one of the few people who actually took time to > review I personally think such kind of things should not to be counted in judging this issue:) > the multivariate stats patch, and I don't quite see this patch > as conflicting with the multivariate one. > > It

Re: [HACKERS] Multi-column distinctness.

Hello, Thank you for pointing that. It is one crucial point of this patch. Sorry for not mentioning on the point. At Sun, 6 Sep 2015 09:24:48 +0100, Simon Riggs wrote in > > Tomas Vondra is now working

Re: [HACKERS] Multi-column distinctness.

Hello, On 09/06/2015 10:24 AM, Simon Riggs wrote: On 28 August 2015 at 09:33, Kyotaro HORIGUCHI > wrote: Tomas Vondra is now working on heavily-equipped multivariate statistics for OLAP usage. In contrast, this is

Re: [HACKERS] Multi-column distinctness.

On 5 September 2015 at 20:46, Bruce Momjian wrote: > On Fri, Aug 28, 2015 at 05:33:34PM +0900, Kyotaro HORIGUCHI wrote: > > Hello, this patch enables planner to be couscious of inter-column > > correlation. > > > > Sometimes two or more columns in a table has some correlation >

Re: [HACKERS] Multi-column distinctness.

On 28 August 2015 at 09:33, Kyotaro HORIGUCHI < horiguchi.kyot...@lab.ntt.co.jp> wrote: > Tomas Vondra is now working on heavily-equipped multivariate > statistics for OLAP usage. In contrast, this is a lightly > implemented solution which calculates only the ratio between a > rows estimated by

Re: [HACKERS] Multi-column distinctness.

Hello Horiguchi-san, On 08/28/2015 10:33 AM, Kyotaro HORIGUCHI wrote: Hello, this patch enables planner to be couscious of inter-column correlation. Sometimes two or more columns in a table has some correlation which brings underestimate, which leads to wrong join method and ends with slow

Re: [HACKERS] Multi-column distinctness.

On Sep 6, 2015 10:31, "Tomas Vondra" wrote: > > 5) syntax > - > The syntax might be one of the pain points if we eventually decide to commit the multivariate stats patch. I have no intention in blocking this patch for that reasons, but if we might design the

Re: [HACKERS] Multi-column distinctness.

On Fri, Aug 28, 2015 at 05:33:34PM +0900, Kyotaro HORIGUCHI wrote: > Hello, this patch enables planner to be couscious of inter-column > correlation. > > Sometimes two or more columns in a table has some correlation > which brings underestimate, which leads to wrong join method and > ends with

[HACKERS] Multi-column distinctness.

Hello, this patch enables planner to be couscious of inter-column correlation. Sometimes two or more columns in a table has some correlation which brings underestimate, which leads to wrong join method and ends with slow execution. Tomas Vondra is now working on heavily-equipped multivariate