On Tue, Jan 5, 2010 at 4:45 PM, Robert Haas wrote:
> On Tue, Dec 29, 2009 at 9:12 PM, Tom Lane wrote:
>> Robert Haas writes:
>>> Yep. It would also lower the barrier to future innovations of that
>>> type, which would be a good thing, IMO. Unfortunately we'd likely
>>> need to continue to supp
decibel writes:
> On Dec 29, 2009, at 6:29 PM, Tom Lane wrote:
>> * when a tabstat message comes in, increment changes_since_analyze by
>> the sum of t_tuples_inserted + t_tuples_updated + t_tuples_deleted;
>>
>> * when an analyze report message comes in, reset changes_since_analyze
>> to zero.
On Dec 29, 2009, at 6:29 PM, Tom Lane wrote:
> * when a tabstat message comes in, increment changes_since_analyze by
> the sum of t_tuples_inserted + t_tuples_updated + t_tuples_deleted;
>
> * when an analyze report message comes in, reset changes_since_analyze
> to zero.
If that's being added, c
On Tue, Dec 29, 2009 at 9:12 PM, Tom Lane wrote:
> Robert Haas writes:
>> Yep. It would also lower the barrier to future innovations of that
>> type, which would be a good thing, IMO. Unfortunately we'd likely
>> need to continue to support the existing syntax at least for
>> attstattarget, whi
On Tue, Jan 5, 2010 at 1:20 PM, Tom Lane wrote:
> Robert Haas writes:
>> It's probably also worth noting that the reason I used DISTINCT
>> originally is because it's already a keyword.
>
> True.
>
> It occurs to me that the pg_stats view already exposes "n_distinct"
> as a column name. I wouldn
Robert Haas writes:
> It's probably also worth noting that the reason I used DISTINCT
> originally is because it's already a keyword.
True.
It occurs to me that the pg_stats view already exposes "n_distinct"
as a column name. I wouldn't object to using "n_distinct" and
"n_distinct_inherited" or
On Tue, Jan 5, 2010 at 1:09 PM, Robert Haas wrote:
> On Tue, Jan 5, 2010 at 1:00 PM, Tom Lane wrote:
>> Robert Haas writes:
>>> Another option would be to call it "inherits_ndistinct", or something
>>> like that, which seems a little more readable, but not great: I don't
>>> think there's going
On Tue, Jan 5, 2010 at 1:00 PM, Tom Lane wrote:
> Robert Haas writes:
>> Another option would be to call it "inherits_ndistinct", or something
>> like that, which seems a little more readable, but not great: I don't
>> think there's going to be any getting around the need to RTFM before
>> settin
Robert Haas writes:
> Another option would be to call it "inherits_ndistinct", or something
> like that, which seems a little more readable, but not great: I don't
> think there's going to be any getting around the need to RTFM before
> setting these parameters.
Well, the previously agreed-to syn
On Tue, Dec 29, 2009 at 9:12 PM, Tom Lane wrote:
> Robert Haas writes:
>> Yep. It would also lower the barrier to future innovations of that
>> type, which would be a good thing, IMO. Unfortunately we'd likely
>> need to continue to support the existing syntax at least for
>> attstattarget, whi
On Wed, Dec 30, 2009 at 10:24 AM, Alvaro Herrera
wrote:
> Tom Lane escribió:
>> Robert Haas writes:
>> > If you'd be willing to look over the latest version of my
>> > per-tablespace random_page_cost/seq_page_cost patch, which I posted to
>> > -hackers some time in the last few days, I can get th
Tom Lane escribió:
> Robert Haas writes:
> > If you'd be willing to look over the latest version of my
> > per-tablespace random_page_cost/seq_page_cost patch, which I posted to
> > -hackers some time in the last few days, I can get that committed and
> > then start working on this, if you'd like.
Robert Haas writes:
> If you'd be willing to look over the latest version of my
> per-tablespace random_page_cost/seq_page_cost patch, which I posted to
> -hackers some time in the last few days, I can get that committed and
> then start working on this, if you'd like.
I think Alvaro would actual
On Tue, Dec 29, 2009 at 9:12 PM, Tom Lane wrote:
> Robert Haas writes:
>> Yep. It would also lower the barrier to future innovations of that
>> type, which would be a good thing, IMO. Unfortunately we'd likely
>> need to continue to support the existing syntax at least for
>> attstattarget, whi
Robert Haas writes:
> Yep. It would also lower the barrier to future innovations of that
> type, which would be a good thing, IMO. Unfortunately we'd likely
> need to continue to support the existing syntax at least for
> attstattarget, which is kind of a bummer, but seems managable. I
> think
On Tue, Dec 29, 2009 at 8:53 PM, Tom Lane wrote:
> Robert Haas writes:
>> Having separate properties for regular attdistinct and inherited
>> attdistinct seems fairly worthwhile, but I share your lack of
>> enthusiasm for solving the problem by adding more columns to
>> pg_attribute. One possibi
Robert Haas writes:
> Having separate properties for regular attdistinct and inherited
> attdistinct seems fairly worthwhile, but I share your lack of
> enthusiasm for solving the problem by adding more columns to
> pg_attribute. One possibility would be to create a new system catalog
> to hold "
On Tue, Dec 29, 2009 at 3:32 PM, Tom Lane wrote:
> I wrote:
>> Following up on the discussion here
>> http://archives.postgresql.org/message-id/4b3875c602250002d...@gw.wicourts.gov
>> I'd like to propose making the following changes that would allow saner
>> planning for queries involving inhe
I wrote:
> 3. Ideally autovacuum would know enough to perform ANALYZEs on
> inheritance parents after enough churn has occurred in their child
> table(s). I am not entirely clear about a good way to do that.
> We could have it just directly force an ANALYZE on parent(s) of any
> table it has chose
I wrote:
> Following up on the discussion here
> http://archives.postgresql.org/message-id/4b3875c602250002d...@gw.wicourts.gov
> I'd like to propose making the following changes that would allow saner
> planning for queries involving inheritance:
I've committed the easy aspects of this (still
Simon Riggs writes:
> On Mon, 2009-12-28 at 17:41 -0500, Tom Lane wrote:
>> 2. When ANALYZE is invoked on a table that has inheritance children,
>> it will perform its normal duties for just that table (creating or
>> updating entries with stainherit = false) and then perform a second
>> scan that
On Mon, 2009-12-28 at 17:41 -0500, Tom Lane wrote:
> Following up on the discussion here
> http://archives.postgresql.org/message-id/4b3875c602250002d...@gw.wicourts.gov
> I'd like to propose making the following changes that would allow saner
> planning for queries involving inheritance:
Sou
Following up on the discussion here
http://archives.postgresql.org/message-id/4b3875c602250002d...@gw.wicourts.gov
I'd like to propose making the following changes that would allow saner
planning for queries involving inheritance:
1. Currently the primary key of pg_statistic is (starelid, staa
23 matches
Mail list logo
