Kim Bisgaard writes:
> Are there plans to make a small follow-up patch to make
> CREATE UNIQUE INDEX on one column
> (and variants in CREATE TABLE ... PRIMARY KEY) automatically do
> SET STATISTICS DISTINCT?
No. It would be pointless for a single column and wrong for
multiple columns.
Are there plans to make a small follow-up patch to make
CREATE UNIQUE INDEX on one column
(and variants in CREATE TABLE ... PRIMARY KEY) automatically do
SET STATISTICS DISTINCT?
It might not be as perfect a solution as teaching the planner to know
about unique indexes, but it is better than not
On Sun, Aug 2, 2009 at 8:35 PM, Tom Lane wrote:
> Robert Haas writes:
>> Thanks. The changes all look good - except I'm curious why %g vs. %f?
>
> So as not to add ".00" unnecessarily. Positive values for ndistinct
> should be treated as integers. (I considered adding an error check to
> re
Robert Haas writes:
> Thanks. The changes all look good - except I'm curious why %g vs. %f?
So as not to add ".00" unnecessarily. Positive values for ndistinct
should be treated as integers. (I considered adding an error check to
reject values like 20.5, but refrained...)
On Sun, Aug 2, 2009 at 6:17 PM, Tom Lane wrote:
> Dimitri Fontaine writes:
>> Yes, and as I didn't have the time to install filterdiff I've attached
>> a revision of your patch in git format which adresses the problem I
>> mentioned, in a tarball also containing raw notes, tests, and
>> regression
Dimitri Fontaine writes:
> Yes, and as I didn't have the time to install filterdiff I've attached
> a revision of your patch in git format which adresses the problem I
> mentioned, in a tarball also containing raw notes, tests, and
> regression.{out,diffs}.
Applied with assorted corrections
On Sun, Aug 02, 2009 at 01:23:27PM -0400, Tom Lane wrote:
> There wasn't any response to this comment:
>
> marcin mank writes:
> > ALTER COLUMN SET DISTINCT
> > feels like adding a unique constraint.
>
> > ALTER COLUMN SET STATISTICS DISTINCT ?
> > ALTER COLUMN SET STATISTICS NDISTINCT ?
>
> I
2009/8/2 Tom Lane :
> There wasn't any response to this comment:
>
> marcin mank writes:
>> ALTER COLUMN SET DISTINCT
>> feels like adding a unique constraint.
>
>> ALTER COLUMN SET STATISTICS DISTINCT ?
>> ALTER COLUMN SET STATISTICS NDISTINCT ?
>
> I don't want to add a new keyword, but "SET STA
There wasn't any response to this comment:
marcin mank writes:
> ALTER COLUMN SET DISTINCT
> feels like adding a unique constraint.
> ALTER COLUMN SET STATISTICS DISTINCT ?
> ALTER COLUMN SET STATISTICS NDISTINCT ?
I don't want to add a new keyword, but "SET STATISTICS DISTINCT" would
be an eas
On Sat, Aug 1, 2009 at 7:27 AM, Dimitri Fontaine wrote:
> Unless you want me to test for impact on planner choices (even if we already
> know it has impact on pg_statistic), I'd say it's ready for commiter.
Great, thanks for the review. I think if stadistinct is getting
populated that's sufficien
Hi,
Le 1 août 09 à 06:08, Robert Haas a écrit :
I'm lost. I think you're getting the new column attdistinct mixed up
with the existing column stadistinct. attdistinct is always going to
have whatever value you assign it. stadistinct will get attdistinct
!= 0 ? attdistinct : .
haha!
Sorry ab
On Fri, Jul 31, 2009 at 11:09 AM, Dimitri
Fontaine wrote:
> I failed to have 0 to allow for analyze to compute a value again, as shown
> in the raw notes in attachement:
I'm lost. I think you're getting the new column attdistinct mixed up
with the existing column stadistinct. attdistinct is alwa
Hi,
Finally some update on the patch.
Le 18 juil. 09 à 20:55, Robert Haas a écrit :
This is one of the things that I hate about the requirement to post
context diffs: filterdiff, at least for me, strips out the git tags
that indicate the base rev of the patch.
Yes, and as I didn't have the ti
Le 29 juil. 09 à 13:07, Robert Haas a écrit :
On Sat, Jul 18, 2009 at 5:54 PM, Dimitri Fontaine> wrote:
I'm going to update the status of patch and resume work on it next
week.
Any update?
Sorry about delays, resuming tomorrow evening is the current plan.
--
dim
--
Sent via pgsql-hackers ma
On Sat, Jul 18, 2009 at 5:54 PM, Dimitri Fontaine wrote:
> I'm going to update the status of patch and resume work on it next week.
Any update?
...Robert
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpre
Le 18 juil. 09 à 20:55, Robert Haas a écrit :
that indicate the base rev of the patch. In fact that rev is BEFORE
the one I based the patch on, which was
64b2da3f7778bc6fd3d213ceb9e73ff3b6e03890, and it actually applies OK
up until 0e3abe7ec78a3d51032d684598f188b0b0304fe9, the commit
immediately
On Fri, Jul 17, 2009 at 11:10 AM, Dimitri Fontaine I
couldn't apply it to current head because of bitrot. It applies fine
to
> git commit bcaef8b5a0e2d5c143dabd8516090a09e39b27b8 [1] but
This is one of the things that I hate about the requirement to post
context diffs: filterdiff, at least for me,
ALTER COLUMN SET DISTINCT
feels like adding a unique constraint.
ALTER COLUMN SET STATISTICS DISTINCT ?
ALTER COLUMN SET STATISTICS NDISTINCT ?
Greetings
Marcin
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org
Hi,
Le 3 mai 09 à 22:13, Robert Haas a écrit :
OK, new version of patch, this time with the weird scaling removed and
the datatype changed to float4.
You've been assigning me this patch review, so here it goes :)
I have not changed the minimum value for remoteVersion in pg_dump.c,
as that wo
On Tue, May 5, 2009 at 12:13 PM, Tom Lane wrote:
> Robert Haas writes:
>> On Mon, May 4, 2009 at 10:41 PM, Joshua Tolley wrote:
>>> A question: why does attdistinct become entry #5 instead of going at the
>>> end?
>>> I assume it's because the order here controls the column order, and it makes
Robert Haas writes:
> On Mon, May 4, 2009 at 10:41 PM, Joshua Tolley wrote:
>> A question: why does attdistinct become entry #5 instead of going at the end?
>> I assume it's because the order here controls the column order, and it makes
>> sense to have attdistinct next to attstattarget, since th
On Mon, May 4, 2009 at 10:41 PM, Joshua Tolley wrote:
> On Mon, May 04, 2009 at 10:13:31PM -0400, Robert Haas wrote:
>
>
>> + own analysis indicates otherwie). When set to a negative value,
>> which
> s/otherwie/otherwise
>
>
>
> A question: why does attdistinct become entry #5 instead o
On Mon, May 04, 2009 at 10:13:31PM -0400, Robert Haas wrote:
> + own analysis indicates otherwie). When set to a negative value, which
s/otherwie/otherwise
A question: why does attdistinct become entry #5 instead of going at the end?
I assume it's because the order here controls the col
On Sun, May 3, 2009 at 3:13 PM, Robert Haas wrote:
> On Mon, Apr 6, 2009 at 11:15 AM, Robert Haas wrote:
>> So based on this comment and Stephen's remarks, I'm going to assume
>> that I'm succumbing to a fit of unjustified paranoia and re-implement
>> as you suggest.
>
> OK, new version of patch,
On Mon, Apr 6, 2009 at 10:49 AM, Tom Lane wrote:
> Robert Haas writes:
>> Well, I think I was pretty clear about what I was trying to
>> accomplish. I think there are more people who care about pg_dump
>> output being diffable than there are who need to set ndistinct more
>> accurately than 1 pp
Robert,
* Robert Haas (robertmh...@gmail.com) wrote:
> On Mon, Apr 6, 2009 at 7:30 AM, Stephen Frost wrote:
> > I do such diffs pretty often, but I don't think I've *ever* done it on
> > catalog tables.. Perhaps it'll come up in the future, but I doubt it.
>
> Well the point is when you dump a
Robert Haas writes:
> Well, I think I was pretty clear about what I was trying to
> accomplish. I think there are more people who care about pg_dump
> output being diffable than there are who need to set ndistinct more
> accurately than 1 ppm and yet not as an integer.
My, you *are* paranoid abo
On Mon, Apr 6, 2009 at 7:30 AM, Stephen Frost wrote:
> * Robert Haas (robertmh...@gmail.com) wrote:
>> Well, I think I was pretty clear about what I was trying to
>> accomplish. I think there are more people who care about pg_dump
>> output being diffable than there are who need to set ndistinct
* Robert Haas (robertmh...@gmail.com) wrote:
> Well, I think I was pretty clear about what I was trying to
> accomplish. I think there are more people who care about pg_dump
> output being diffable than there are who need to set ndistinct more
> accurately than 1 ppm and yet not as an integer. Pe
On Sun, Apr 5, 2009 at 11:33 PM, Tom Lane wrote:
> Robert Haas writes:
>> (It's also worth pointing out that the calculations we do with
>> ndistinct are pretty approximations anyway. If the difference between
>> stadistinct = -1 x 10^-6 and stadistinct = -1.4^10-6 is the thing
>> that's determi
Robert Haas writes:
> (It's also worth pointing out that the calculations we do with
> ndistinct are pretty approximations anyway. If the difference between
> stadistinct = -1 x 10^-6 and stadistinct = -1.4^10-6 is the thing
> that's determining whether the planner is picking the correct plan on
On Sun, Apr 5, 2009 at 10:38 PM, Robert Haas wrote:
> On Sun, Apr 5, 2009 at 10:00 PM, Tom Lane wrote:
>> Robert Haas writes:
>>> On Sun, Apr 5, 2009 at 7:56 PM, Tom Lane wrote:
[ shrug... ] Precision is not important for this value: we are not
anywhere near needing more than six sig
On Sun, Apr 5, 2009 at 10:00 PM, Tom Lane wrote:
> Robert Haas writes:
>> On Sun, Apr 5, 2009 at 7:56 PM, Tom Lane wrote:
>>> [ shrug... ] Precision is not important for this value: we are not
>>> anywhere near needing more than six significant digits for our
>>> statistical estimates. Range,
Robert Haas writes:
> On Sun, Apr 5, 2009 at 7:56 PM, Tom Lane wrote:
>> [ shrug... ] Precision is not important for this value: we are not
>> anywhere near needing more than six significant digits for our
>> statistical estimates. Range, on the other hand, could be important
>> when dealing wi
On Sun, Apr 5, 2009 at 7:56 PM, Tom Lane wrote:
> Robert Haas writes:
>> On Sat, Apr 4, 2009 at 11:14 PM, Tom Lane wrote:
>>> * Using an integer is bogus. Use a float4 and forget the weird scaling;
>>> it should have exactly the same interpretation as stadistinct, except
>>> for 0 meaning "unse
Robert Haas writes:
> On Sat, Apr 4, 2009 at 11:14 PM, Tom Lane wrote:
>> * Using an integer is bogus. Use a float4 and forget the weird scaling;
>> it should have exactly the same interpretation as stadistinct, except
>> for 0 meaning "unset" instead of "unknown".
> I have a deep-seated aversi
On Sat, Apr 4, 2009 at 11:14 PM, Tom Lane wrote:
> Robert Haas writes:
>> On Sat, Apr 4, 2009 at 7:04 PM, Tom Lane wrote:
>>> I'm not thrilled about adding a column to pg_attribute for this.
>
>> What is the specific nature of your concern?
>
> Actually, I'm more worried about the TupleDesc data
Robert Haas writes:
> On Sat, Apr 4, 2009 at 7:04 PM, Tom Lane wrote:
>> I'm not thrilled about adding a column to pg_attribute for this.
> What is the specific nature of your concern?
Actually, I'm more worried about the TupleDesc data structure than
the catalogs. There are TupleDescs all ove
On Sat, Apr 4, 2009 at 10:31 PM, Alvaro Herrera
wrote:
> Robert Haas escribió:
>> On Sat, Apr 4, 2009 at 7:04 PM, Tom Lane wrote:
>> > Robert Haas writes:
>> >> Per previous discussion.
>> >> http://archives.postgresql.org/message-id/8066.1229106...@sss.pgh.pa.us
>> >> http://archives.postgresql
Alvaro Herrera writes:
> FWIW it has been said that whoever is concerned about pg_attribute bloat
> should be first looking at getting rid of the redundant entries for
> system columns, for each and every table.
That's been overtaken by events, unfortunately: we now need those
entries to carry pe
Robert Haas escribió:
> On Sat, Apr 4, 2009 at 7:04 PM, Tom Lane wrote:
> > Robert Haas writes:
> >> Per previous discussion.
> >> http://archives.postgresql.org/message-id/8066.1229106...@sss.pgh.pa.us
> >> http://archives.postgresql.org/message-id/603c8f070904021926g92eb55sdfc6814113395...@mail
On Sat, Apr 4, 2009 at 7:04 PM, Tom Lane wrote:
> Robert Haas writes:
>> Per previous discussion.
>> http://archives.postgresql.org/message-id/8066.1229106...@sss.pgh.pa.us
>> http://archives.postgresql.org/message-id/603c8f070904021926g92eb55sdfc6814113395...@mail.gmail.com
>
> I'm not thrilled
Robert Haas writes:
> Per previous discussion.
> http://archives.postgresql.org/message-id/8066.1229106...@sss.pgh.pa.us
> http://archives.postgresql.org/message-id/603c8f070904021926g92eb55sdfc6814113395...@mail.gmail.com
I'm not thrilled about adding a column to pg_attribute for this.
Isn't the
43 matches
Mail list logo
