Thanks for the quick response, I would like to add a patch to postgres to do a simple check for one table, since this is straight forward. Unfortunatly, I am not familiar too much with postgres source code. So my question is , what are the source files that I need to check and can you please point me to the appropriate developer guide.
Regards
From: Tom Lane <tgl@xxxxxxxxxxxxx>
To: Kevin Grittner <kgrittn@xxxxxxxx>
Cc: salah jubeh <s_jubeh@xxxxxxxxx>; pgsql <pgsql-general@xxxxxxxxxxxxxx>
Sent: Friday, January 18, 2013 2:02 AM
Subject: Re: SELECT DISTINCT
"Kevin Grittner" <kgrittn@xxxxxxxx> writes:
> salah jubeh wrote:
>> I think any query that returns a unique column (primary key,
>> unique) which is not duplicated in some way (join) can use this
>> optimisation technique.
> I agree that if the planner searched for that, there would be cases
> where the DISTINCT keyword could be determined to be a noise word.
> The problem with that is that such searching in the planner would
> not be free -- doing it accurately would increase planning cost for
> every query which was legitimately using the feature.
There is actually infrastructure in the planner that could be used for
this, at least for the case where the query selects from just one base
table. I tend to agree though that adding such a check to every
DISTINCT query would be slowing everybody down to benefit only dubious
queries. It would be easier to swallow the overhead if there were a
solid case that reasonably-written queries might sometimes need the
optimization.
regards, tom lane
--
Sent via pgsql-general mailing list (pgsql-general@xxxxxxxxxxxxxx)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-general
Regards
From: Tom Lane <tgl@xxxxxxxxxxxxx>
To: Kevin Grittner <kgrittn@xxxxxxxx>
Cc: salah jubeh <s_jubeh@xxxxxxxxx>; pgsql <pgsql-general@xxxxxxxxxxxxxx>
Sent: Friday, January 18, 2013 2:02 AM
Subject: Re: SELECT DISTINCT
"Kevin Grittner" <kgrittn@xxxxxxxx> writes:
> salah jubeh wrote:
>> I think any query that returns a unique column (primary key,
>> unique) which is not duplicated in some way (join) can use this
>> optimisation technique.
> I agree that if the planner searched for that, there would be cases
> where the DISTINCT keyword could be determined to be a noise word.
> The problem with that is that such searching in the planner would
> not be free -- doing it accurately would increase planning cost for
> every query which was legitimately using the feature.
There is actually infrastructure in the planner that could be used for
this, at least for the case where the query selects from just one base
table. I tend to agree though that adding such a check to every
DISTINCT query would be slowing everybody down to benefit only dubious
queries. It would be easier to swallow the overhead if there were a
solid case that reasonably-written queries might sometimes need the
optimization.
regards, tom lane
--
Sent via pgsql-general mailing list (pgsql-general@xxxxxxxxxxxxxx)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-general
