SEO

I'd love to see this back patched into 8.2.1 if possible.

Should I resubmit with new names?

-Glen

Bruce Momjian wrote:
> Is this something we want in 8.3? I am thinking visible/expired would
> be clearer terms.
>
> ---------------------------------------------------------------------------
>
> Glen Parker wrote:
>> This patch consists of two c functions to expose n_live_tuples and
>> n_dead_tuples, SQL functions to expose them to SQL land, and
>> corresponding fields added to pg_stat_all_tables.
>>
>> This has been discussed in general. The purpose is to allow
>> autovacuum-esq conditional vacuuming and clustering using SQL to
>> discover the required stats.


---------------------------(end of broadcast)---------------------------
TIP 9: In versions below 8.0, the planner will ignore your desire to
choose an index scan if your joining column's datatypes do not
match

On Tue, 2006-12-26 at 13:59 -0800, Glen Parker wrote:
> I'd love to see this back patched into 8.2.1 if possible.

Probably not. We typically do not introduce new features into back
releases.

Sincerely,

Joshua D. Drake


>
> Should I resubmit with new names?
>
> -Glen
>
> Bruce Momjian wrote:
> > Is this something we want in 8.3? I am thinking visible/expired would
> > be clearer terms.
> >
> > ---------------------------------------------------------------------------
> >
> > Glen Parker wrote:
> >> This patch consists of two c functions to expose n_live_tuples and
> >> n_dead_tuples, SQL functions to expose them to SQL land, and
> >> corresponding fields added to pg_stat_all_tables.
> >>
> >> This has been discussed in general. The purpose is to allow
> >> autovacuum-esq conditional vacuuming and clustering using SQL to
> >> discover the required stats.
>
>
> ---------------------------(end of broadcast)---------------------------
> TIP 9: In versions below 8.0, the planner will ignore your desire to
> choose an index scan if your joining column's datatypes do not
> match
>
--

=== The PostgreSQL Company: Command Prompt, Inc. ===
Sales/Support: +1.503.667.4564 || 24x7/Emergency: +1.800.492.2240
Providing the most comprehensive PostgreSQL solutions since 1997
http://www.commandprompt.com/

Donate to the PostgreSQL Project: http://www.postgresql.org/about/donate




---------------------------(end of broadcast)---------------------------
TIP 1: if posting/reading through Usenet, please send an appropriate
subscribe-nomail command to majordomo@postgresql.org so that your
message can get through to the mailing list cleanly

"Joshua D. Drake" <jd@commandprompt.com> writes:
> On Tue, 2006-12-26 at 13:59 -0800, Glen Parker wrote:
>> I'd love to see this back patched into 8.2.1 if possible.

> Probably not. We typically do not introduce new features into back
> releases.

And since this one would require an initdb, there is exactly zero chance
of it being back-patched ...

regards, tom lane

---------------------------(end of broadcast)---------------------------
TIP 9: In versions below 8.0, the planner will ignore your desire to
choose an index scan if your joining column's datatypes do not
match

Glen Parker wrote:

[slightly reformatted for sanity]

> Bruce Momjian wrote:
> >Is this something we want in 8.3? I am thinking visible/expired would
> >be clearer terms.
>
> I'd love to see this back patched into 8.2.1 if possible.
>
> Should I resubmit with new names?

I'm not really convinced that Bruce's proposed names seem any better to
me. What's wrong with "dead" and "live"?

As for backpatching, you already knew the answer :-)

--
Alvaro Herrera http://www.CommandPrompt.com/
The PostgreSQL Company - Command Prompt, Inc.

---------------------------(end of broadcast)---------------------------
TIP 5: don't forget to increase your free space map settings

Alvaro Herrera wrote:
> As for backpatching, you already knew the answer :-)

Nope, I had no idea this would require initdb...

-Glen

---------------------------(end of broadcast)---------------------------
TIP 2: Don't 'kill -9' the postmaster

Glen Parker wrote:
> Alvaro Herrera wrote:
>> As for backpatching, you already knew the answer :-)
>
> Nope, I had no idea this would require initdb...
>
>

Regardless of this, our rule against backpatching new features is well
founded. The stable branches are called stable for a good reason.

cheers

andrew


---------------------------(end of broadcast)---------------------------
TIP 7: You can help support the PostgreSQL project by donating at

http://www.postgresql.org/about/donate

Alvaro Herrera wrote:
> Glen Parker wrote:
>
> [slightly reformatted for sanity]
>
> > Bruce Momjian wrote:
> > >Is this something we want in 8.3? I am thinking visible/expired would
> > >be clearer terms.
> >
> > I'd love to see this back patched into 8.2.1 if possible.
> >
> > Should I resubmit with new names?
>
> I'm not really convinced that Bruce's proposed names seem any better to
> me. What's wrong with "dead" and "live"?

With MVCC, my thought has always been that alive/dead is in the eye of
the beholder/backend. For column names the user will see, I think we
need to use terms that we have used in the past. If we want to move to
alive/dead, fine, but we then need to make sure we use consistent terms
in the documentation.

In my mind, visible really means "visible to anyone", and expired means
visible to no one. I don't think live/dead can be as clear as
visible/expired, e.g. saying the tuple is "live to someone" seems
more awkward.

--
Bruce Momjian bruce@momjian.us
EnterpriseDB http://www.enterprisedb.com

+ If your life is a hard drive, Christ can be your backup. +

---------------------------(end of broadcast)---------------------------
TIP 9: In versions below 8.0, the planner will ignore your desire to
choose an index scan if your joining column's datatypes do not
match

Bruce Momjian <bruce@momjian.us> writes:
> Alvaro Herrera wrote:
>> I'm not really convinced that Bruce's proposed names seem any better to
>> me. What's wrong with "dead" and "live"?

> In my mind, visible really means "visible to anyone", and expired means
> visible to no one.

Um ... surely, visibility is in the eye of the beholder (no smiley).

I don't have an immediate suggestion for better terminology, but IMHO
the whole point of visible/invisible terminology is that it depends on
who's looking. Dead and live seem to convey a more appropriate air
of finality.

"Expired" is OK as a synonym for "dead", but there is no thesaurus
anywhere in the world that will suggest it as an antonym for "visible".

regards, tom lane

---------------------------(end of broadcast)---------------------------
TIP 4: Have you searched our list archives?

http://archives.postgresql.org

Tom Lane wrote:
> Bruce Momjian <bruce@momjian.us> writes:
> > Alvaro Herrera wrote:
> >> I'm not really convinced that Bruce's proposed names seem any better to
> >> me. What's wrong with "dead" and "live"?
>
> > In my mind, visible really means "visible to anyone", and expired means
> > visible to no one.
>
> Um ... surely, visibility is in the eye of the beholder (no smiley).
>
> I don't have an immediate suggestion for better terminology, but IMHO
> the whole point of visible/invisible terminology is that it depends on
> who's looking. Dead and live seem to convey a more appropriate air
> of finality.
>
> "Expired" is OK as a synonym for "dead", but there is no thesaurus
> anywhere in the world that will suggest it as an antonym for "visible".

OK, so we need new terminology and we need it to be used consistenly in
our documentation, whatever we choose.

--
Bruce Momjian bruce@momjian.us
EnterpriseDB http://www.enterprisedb.com

+ If your life is a hard drive, Christ can be your backup. +

---------------------------(end of broadcast)---------------------------
TIP 9: In versions below 8.0, the planner will ignore your desire to
choose an index scan if your joining column's datatypes do not
match

On Tuesday 26 December 2006 23:12, Bruce Momjian wrote:
> Tom Lane wrote:
> > Bruce Momjian <bruce@momjian.us> writes:
> > > Alvaro Herrera wrote:
> > >> I'm not really convinced that Bruce's proposed names seem any better
> > >> to me. What's wrong with "dead" and "live"?
> > >
> > > In my mind, visible really means "visible to anyone", and expired means
> > > visible to no one.
> >
> > Um ... surely, visibility is in the eye of the beholder (no smiley).
> >
> > I don't have an immediate suggestion for better terminology, but IMHO
> > the whole point of visible/invisible terminology is that it depends on
> > who's looking. Dead and live seem to convey a more appropriate air
> > of finality.
> >
> > "Expired" is OK as a synonym for "dead", but there is no thesaurus
> > anywhere in the world that will suggest it as an antonym for "visible".
>
> OK, so we need new terminology and we need it to be used consistenly in
> our documentation, whatever we choose.

The current terminology of live and dead is already used in many places in the
documentation and in userspace; mostly around the need for maintainance of
dead tuples within tables, reindex cleaning up dead pages, and even in the
vacuum commands output (n dead tuples cannot be removed yet). Given this
patch came from userland, istm people are comfortable enough with this
terminology there is no need to change it.

--
Robert Treat
Build A Brighter LAMP :: Linux Apache {middleware} PostgreSQL

---------------------------(end of broadcast)---------------------------
TIP 9: In versions below 8.0, the planner will ignore your desire to
choose an index scan if your joining column's datatypes do not
match