On Tue, Jan 5, 2010 at 4:45 PM, Robert Haas robertmh...@gmail.com wrote:
On Tue, Dec 29, 2009 at 9:12 PM, Tom Lane t...@sss.pgh.pa.us wrote:
Robert Haas robertmh...@gmail.com writes:
Yep. It would also lower the barrier to future innovations of that
type, which would be a good thing, IMO.
decibel deci...@decibel.org 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
On Tue, Dec 29, 2009 at 9:12 PM, Tom Lane t...@sss.pgh.pa.us wrote:
Robert Haas robertmh...@gmail.com 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
Robert Haas robertmh...@gmail.com 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
On Tue, Jan 5, 2010 at 1:00 PM, Tom Lane t...@sss.pgh.pa.us wrote:
Robert Haas robertmh...@gmail.com 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
On Tue, Jan 5, 2010 at 1:09 PM, Robert Haas robertmh...@gmail.com wrote:
On Tue, Jan 5, 2010 at 1:00 PM, Tom Lane t...@sss.pgh.pa.us wrote:
Robert Haas robertmh...@gmail.com writes:
Another option would be to call it inherits_ndistinct, or something
like that, which seems a little more
Robert Haas robertmh...@gmail.com 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
On Tue, Jan 5, 2010 at 1:20 PM, Tom Lane t...@sss.pgh.pa.us wrote:
Robert Haas robertmh...@gmail.com 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
On Tue, Dec 29, 2009 at 9:12 PM, Tom Lane t...@sss.pgh.pa.us wrote:
Robert Haas robertmh...@gmail.com 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
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, could
Robert Haas robertmh...@gmail.com 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
Tom Lane escribió:
Robert Haas robertmh...@gmail.com 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,
On Wed, Dec 30, 2009 at 10:24 AM, Alvaro Herrera
alvhe...@commandprompt.com wrote:
Tom Lane escribió:
Robert Haas robertmh...@gmail.com 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
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:
Sounds
Simon Riggs si...@2ndquadrant.com 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
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
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 chosen to
On Tue, Dec 29, 2009 at 3:32 PM, Tom Lane t...@sss.pgh.pa.us 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
Robert Haas robertmh...@gmail.com 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
On Tue, Dec 29, 2009 at 8:53 PM, Tom Lane t...@sss.pgh.pa.us wrote:
Robert Haas robertmh...@gmail.com 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
Robert Haas robertmh...@gmail.com 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
On Tue, Dec 29, 2009 at 9:12 PM, Tom Lane t...@sss.pgh.pa.us wrote:
Robert Haas robertmh...@gmail.com 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
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,
23 matches
Mail list logo
