Horton

Thread

  1. having and union in v7beta

    Jose Soares <jose@sferacarta.com> — 2000-02-28T14:13:51Z

    I'm comparing v6.5.2 against v7.0 and I see now:
UPDATEs and INSERTs  are faster in v7.0 than v5.6.2 but
SELECTs are slow, specially:
SELECT ... UNION (is 3 / 4 times slow)
and
SELECT...HAVING, this last for example doesn't work.

I'm waiting for hours to have the result of following query:

EXPLAIN select * from comuni where nome in
(select nome from comuni group by nome having 1 < count(nome));

Seq Scan on comuni  (cost=0.00..3429753.65 rows=8342 width=84)
  SubPlan
    ->  Aggregate  (cost=0.00..822.22 rows=834 width=12)
          ->  Group  (cost=0.00..801.37 rows=8342 width=12)
                ->  Index Scan using knome on comuni  (cost=0.00..780.51
rows=8)

EXPLAIN

--
Jose' Soares
Bologna, Italy                     Jose@sferacarta.com

  2. Re: [HACKERS] having and union in v7beta

    Tom Lane <tgl@sss.pgh.pa.us> — 2000-02-28T15:14:07Z

    Jose Soares <jose@sferacarta.com> writes:
> SELECT...HAVING, this last for example doesn't work.

That's a rather strong statement, and in fact a provably false one.
How about a detailed bug report rather than "it doesn't work"?

> SELECT ... UNION (is 3 / 4 times slow)

Can't help you on that without more details, either.  What is the
query exactly, what plan does EXPLAIN show, and what plan did you
get from 6.5?

			regards, tom lane

  3. Re: [HACKERS] having and union in v7beta

    Jose Soares <jose@sferacarta.com> — 2000-02-28T15:51:38Z

    
Tom Lane wrote:

> Jose Soares <jose@sferacarta.com> writes:
> > SELECT...HAVING, this last for example doesn't work.
>
> That's a rather strong statement, and in fact a provably false one.
> How about a detailed bug report rather than "it doesn't work"?
>
> > SELECT ... UNION (is 3 / 4 times slow)
>
> Can't help you on that without more details, either.  What is the
> query exactly, what plan does EXPLAIN show, and what plan did you
> get from 6.5?
>
>                         regards, tom lane




--
Jose' Soares
Bologna, Italy                     Jose@sferacarta.com

  4. Re: [HACKERS] having and union in v7beta

    Tom Lane <tgl@sss.pgh.pa.us> — 2000-02-29T00:16:15Z

    Jose Soares <jose@sferacarta.com> writes:
>>>> SELECT ... UNION (is 3 / 4 times slow)
>> 
>> Can't help you on that without more details, either.  What is the
>> query exactly, what plan does EXPLAIN show, and what plan did you
>> get from 6.5?

> psql7=> EXPLAIN select distretto from comuni union select codice_fiscale from comuni;
> NOTICE:  QUERY PLAN:

> Unique  (cost=1767.19..1808.90 rows=1668 width=12)
-> Sort  (cost=1767.19..1767.19 rows=16684 width=12)
-> Append  (cost=0.00..464.84 rows=16684 width=12)
-> Seq Scan on comuni  (cost=0.00..232.42 rows=8342 width=12)
-> Seq Scan on comuni  (cost=0.00..232.42 rows=8342 width=12)

> [ and exactly the same plan for 6.5 ]

OK, so much for my first thought that the 7.0 planner was choosing a
bad plan.

One relevant change is that Unique nodes now invoke the proper
type-specific equality function(s) to decide whether tuples are distinct
or not, instead of doing a bitwise comparison (memcmp()) like they did
before.  But it's tough to believe that that accounts for a 3-to-4x
slowdown of this query; certainly I don't see much performance
difference on the datatypes I tried.  What datatypes are your fields,
anyway?

The other possibility is that the Sort step is a lot slower in 7.0,
although I don't think it should be.  Are you running both versions
with the same -S setting, and if so what is it?  Could it be that
the query is right on the edge of needing to switch from memory-based
to disk-based sort?  Perhaps 7.0 is deciding that it needs to go to
disk a little sooner than 6.5 did.

			regards, tom lane

  5. Re: [HACKERS] having and union in v7beta

    Jose Soares <jose@sferacarta.com> — 2000-02-29T08:07:11Z

    
Tom Lane wrote:

> Jose Soares <jose@sferacarta.com> writes:
> > SELECT...HAVING, this last for example doesn't work.
>
> That's a rather strong statement, and in fact a provably false one.
> How about a detailed bug report rather than "it doesn't work"?
>
> > SELECT ... UNION (is 3 / 4 times slow)
>
> Can't help you on that without more details, either.  What is the
> query exactly, what plan does EXPLAIN show, and what plan did you
> get from 6.5?
>
>                         regards, tom lane

--
Jose' Soares
Bologna, Italy                     Jose@sferacarta.com

  6. Re: [HACKERS] having and union in v7beta

    Jose Soares <jose@sferacarta.com> — 2000-02-29T08:34:59Z

    
Tom Lane wrote:

> Jose Soares <jose@sferacarta.com> writes:
> >>>> SELECT ... UNION (is 3 / 4 times slow)
> >>
> >> Can't help you on that without more details, either.  What is the
> >> query exactly, what plan does EXPLAIN show, and what plan did you
> >> get from 6.5?
>
> > psql7=> EXPLAIN select distretto from comuni union select codice_fiscale from comuni;
> > NOTICE:  QUERY PLAN:
>
> > Unique  (cost=1767.19..1808.90 rows=1668 width=12)
> -> Sort  (cost=1767.19..1767.19 rows=16684 width=12)
> -> Append  (cost=0.00..464.84 rows=16684 width=12)
> -> Seq Scan on comuni  (cost=0.00..232.42 rows=8342 width=12)
> -> Seq Scan on comuni  (cost=0.00..232.42 rows=8342 width=12)
>
> > [ and exactly the same plan for 6.5 ]
>
> OK, so much for my first thought that the 7.0 planner was choosing a
> bad plan.
>
> One relevant change is that Unique nodes now invoke the proper
> type-specific equality function(s) to decide whether tuples are distinct
> or not, instead of doing a bitwise comparison (memcmp()) like they did
> before.  But it's tough to believe that that accounts for a 3-to-4x
> slowdown of this query; certainly I don't see much performance
> difference on the datatypes I tried.  What datatypes are your fields,
> anyway?

6.5 takes 0.463s
7.0 takes 1.640s
the field type is CHAR(4)

>
>
> The other possibility is that the Sort step is a lot slower in 7.0,
> although I don't think it should be.  Are you running both versions
> with the same -S setting, and if so what is it?  Could it be that
>

 I'm running both of them in this way:
postmaster -i -o -F -B 512 -S > server.log 2>&1

> the query is right on the edge of needing to switch from memory-based
> to disk-based sort?  Perhaps 7.0 is deciding that it needs to go to
> disk a little sooner than 6.5 did.
>
>                         regards, tom lane

--
Jose' Soares
Bologna, Italy                     Jose@sferacarta.com

  7. Re: [HACKERS] having and union in v7beta

    Tom Lane <tgl@sss.pgh.pa.us> — 2000-02-29T18:27:41Z

    Jose Soares <jose@sferacarta.com> writes:
>> But it's tough to believe that that accounts for a 3-to-4x
>> slowdown of this query; certainly I don't see much performance
>> difference on the datatypes I tried.  What datatypes are your fields,
>> anyway?

> 6.5 takes 0.463s
> 7.0 takes 1.640s
> the field type is CHAR(4)

Hmm.  I see no more than a few percent difference between 6.5 and
current.  There's something peculiar going on on your system.

Current code would ultimately invoke strncmp() on the two char fields,
whereas 6.5 used memcmp().  Is it possible that strncmp() is a huge
performance dog on your platform?  I assume you are running in a
non-ASCII locale, which might reduce strncmp's performance, but still...

A quick-and-dirty way for you to check this would be to change the
strncmp call to call memcmp (just the one-word change should work)
in bpchareq() in src/backend/utils/adt/varchar.c, and see if that
changes the performance of this query materially.

			regards, tom lane

  8. Re: [HACKERS] having and union in v7beta

    Tom Lane <tgl@sss.pgh.pa.us> — 2000-02-29T19:49:53Z

    Jose Soares <jose@sferacarta.com> writes:
> I tried the following query :

> select * from comuni where nome in (
>      select nome from comuni group by nome having 1 < count(nome)
>      );

> on the above table populated with 8342 rows, PostgreSQL begins searching
> and I wait for hours without any result.

I'd expect that to be pretty slow, since it's going to execute the inner
select for every tuple examined by the outer select.  Shouldn't be any
worse than 6.5 though.  IN (sub-SELECT) has always been slow.

The real solution is to figure out how to do this kind of thing via
joins, but that will have to wait for the fabled querytree redesign.

I have been toying with the notion of sticking a MATERIALIZE node
into the plan tree when we have an IN sub-select and the sub-plan is
complicated, but has no parameters passed from the upper plan.
(Not sure yet how complicated is complicated enough, but a plan that
requires sorting or indexscanning should qualify.)  The MATERIALIZE
node would run the sub-plan just once and stash the output tuples in
a temp table; then we'd only need a simple scan of the temp table for
each outer tuple.  I think that would improve the speed of IN
sub-SELECTs by a useful amount in many cases, and it'd be a lot easier
than the "real" solution.

However, I'm not sure it's a good idea to do this when we've already
started beta.  Should I try it, or leave it alone until 7.1?  By 7.1
it might be moot...

			regards, tom lane

  9. Re: [HACKERS] having and union in v7beta

    Jose Soares <jose@sferacarta.com> — 2000-03-01T12:22:23Z

    
Tom Lane wrote:

> Jose Soares <jose@sferacarta.com> writes:
> >> But it's tough to believe that that accounts for a 3-to-4x
> >> slowdown of this query; certainly I don't see much performance
> >> difference on the datatypes I tried.  What datatypes are your fields,
> >> anyway?
>
> > 6.5 takes 0.463s
> > 7.0 takes 1.640s
> > the field type is CHAR(4)
>
> Hmm.  I see no more than a few percent difference between 6.5 and
> current.  There's something peculiar going on on your system.
>
> Current code would ultimately invoke strncmp() on the two char fields,
> whereas 6.5 used memcmp().  Is it possible that strncmp() is a huge
> performance dog on your platform?  I assume you are running in a
> non-ASCII locale, which might reduce strncmp's performance, but still...
>
> A quick-and-dirty way for you to check this would be to change the
> strncmp call to call memcmp (just the one-word change should work)
> in bpchareq() in src/backend/utils/adt/varchar.c, and see if that
> changes the performance of this query materially.
>
>                         regards, tom lane
>

tests with strncmp:
^^^^^^^^^^^^^^^^^^^
$ time psql hygea1 -c 'select * from comuni union select * from comuni' >
/dev/n
real    0m1.685s
user    0m0.190s
sys     0m0.050s
$ time psql hygea1 -c 'select * from comuni union select * from comuni' >
/dev/n
real    0m1.681s
user    0m0.200s
sys     0m0.060s
$ time psql hygea1 -c 'select * from comuni union select * from comuni' >
/dev/n
real    0m1.680s
user    0m0.140s
sys     0m0.020s
$ time psql hygea1 -c 'select * from comuni union select * from comuni' >
/dev/n
real    0m1.695s
user    0m0.220s
sys     0m0.010s
$ time psql hygea1 -c 'select * from comuni union select * from comuni' >
/dev/n
real    0m1.681s
user    0m0.150s
sys     0m0.020s
=========================================
tests with memcmp:
^^^^^^^^^^^^^^^^^^
$ time psql hygea1 -c 'select * from comuni union select * from comuni' >
/dev/n
real    0m1.714s
user    0m0.220s
sys     0m0.010s
$ time psql hygea1 -c 'select * from comuni union select * from comuni' >
/dev/n
real    0m1.696s
user    0m0.190s
sys     0m0.010s
$ time psql hygea1 -c 'select * from comuni union select * from comuni' >
/dev/n
real    0m1.702s
user    0m0.220s
sys     0m0.010s
$ time psql hygea1 -c 'select * from comuni union select * from comuni' >
/dev/n
real    0m1.693s
user    0m0.190s
sys     0m0.020s
$ time psql hygea1 -c 'select * from comuni union select * from comuni' >
/dev/n
real    0m1.692s
user    0m0.180s
sys     0m0.030s
======================================



--
Jose' Soares
Bologna, Italy                     Jose@sferacarta.com

  10. Re: [HACKERS] having and union in v7beta

    Jose Soares <jose@sferacarta.com> — 2000-03-01T13:24:14Z

    Tom Lane wrote:

> Jose Soares <jose@sferacarta.com> writes:
> > I tried the following query :
>
> > select * from comuni where nome in (
> >      select nome from comuni group by nome having 1 < count(nome)
> >      );
>
> > on the above table populated with 8342 rows, PostgreSQL begins searching
> > and I wait for hours without any result.
>
> I'd expect that to be pretty slow, since it's going to execute the inner
> select for every tuple examined by the outer select.  Shouldn't be any
> worse than 6.5 though.  IN (sub-SELECT) has always been slow.
>
>

In v7.0 this query takes more than 50min to execute, it doesn't work on
v6.5...

select * from comuni where nome in (
     select nome from comuni group by nome having count(nome) > 1
     );

real    50m25.033s
user    0m0.010s
sys     0m0.000s

--
Jose' Soares
Bologna, Italy                     Jose@sferacarta.com

  11. rpms

    Sergio A. Kessler <sak@tribctas.gba.gov.ar> — 2000-03-01T13:38:40Z

    Lamars,

it shouldn't be better to rename the package postgresql-xxx.rpm
to postgresql-libs-xxx.rpm ??

actually is quite confusing, because at first look it seems that
this package is the real thing (then you discover that is not,
that the package you really want is postgresql-server).


Sergio

  12. Re: [HACKERS] rpms

    Thomas Lockhart <lockhart@alumni.caltech.edu> — 2000-03-01T14:00:27Z

    > it shouldn't be better to rename the package postgresql-xxx.rpm
> to postgresql-libs-xxx.rpm ??
> actually is quite confusing, because at first look it seems that
> this package is the real thing (then you discover that is not,
> that the package you really want is postgresql-server).

Actually, what you suggest was how the naming was in earlier RPMs.
However, I changed the naming convention since the fundamental
installation should require client-side code only, to talk to a remote
server. In cases where Postgres is deployed on many machines, only one
or a few will have the server installed, while all machines will get
the client packages.

Regards.

                   - Thomas

-- 
Thomas Lockhart				lockhart@alumni.caltech.edu
South Pasadena, California

  13. Re: [HACKERS] rpms

    Sergio A. Kessler <sak@tribctas.gba.gov.ar> — 2000-03-01T14:25:26Z

    Thomas Lockhart <lockhart@alumni.caltech.edu> el día Wed, 01 Mar 2000 
14:00:27 +0000, escribió:

>> it shouldn't be better to rename the package postgresql-xxx.rpm
>> to postgresql-libs-xxx.rpm ??
>> actually is quite confusing, because at first look it seems that
>> this package is the real thing (then you discover that is not,
>> that the package you really want is postgresql-server).
>
>Actually, what you suggest was how the naming was in earlier RPMs.
>However, I changed the naming convention since the fundamental
>installation should require client-side code only, to talk to a remote
>server. In cases where Postgres is deployed on many machines, only one
>or a few will have the server installed, while all machines will get
>the client packages.

hi thomas; yup, I agree that the client side is more deployed,
and that the packages should be split into server for one side
and libs in other side.
and I don't have problems with this, I just have problems 
with the =name= of the package that contain the libs.

it should be clear that the package contains ONLY the client side,
a package just named "postgresql" appear like it contains PostgreSql,
when this, in fact, is not true.

just like postgresql-server.xxx.rpm, this package is well named IMO
(is pretty clear that it contains the PostgreSql server)

what is more clear/descriptive to you for a package that ONLY 
contains PostgreSql libraries:

a)  postgresql-libs.xxx.rpm  (or maybe postgresql-clientlibs.xxx.rpm ?)
b)  postgresql.xxx.rpm

??


Sergio

  14. Re: [HACKERS] rpms

    Sergio A. Kessler <sak@tribctas.gba.gov.ar> — 2000-03-01T14:39:46Z

    "Sergio A. Kessler" <sak@tribctas.gba.gov.ar> el día Wed, 1 Mar 2000 
11:25:26 -0300, escribió:

>what is more clear/descriptive to you for a package that ONLY 
>contains PostgreSql libraries:
>
>a)  postgresql-libs.xxx.rpm  (or maybe postgresql-clientlibs.xxx.rpm ?)
>b)  postgresql.xxx.rpm
>
>??

and another argument:   :)

suposse a newbie looking for a RDBM is told to install PostgreSql,
what you think will be the first package he will try ?

Sergio

  15. Re: [HACKERS] rpms

    Thomas Lockhart <lockhart@alumni.caltech.edu> — 2000-03-01T16:33:52Z

    > >what is more clear/descriptive to you for a package that ONLY
> >contains PostgreSql libraries:
> >a)  postgresql-libs.xxx.rpm  (or maybe postgresql-clientlibs.xxx.rpm ?)
> >b)  postgresql.xxx.rpm
> suposse a newbie looking for a RDBM is told to install PostgreSql,
> what you think will be the first package he will try ?

Well, the newbie would be best off if he installed every package ;)

Anyway, afaik most RPM distros of a product have one .rpm file which
has the name of the package, and then may have other .rpm files which
have qualifiers, like "-server". So in choosing which .rpm file will
be the base package, it seemed most appropriate that it be the
client-side stuff, as opposed to docs, or server (which btw can't
really be run on its own without the client stuff installed
*somewhere*), or something else.

I appreciate your points, but it isn't clear to me how to eliminate
*all* possibilities for confusion via RPM package names, so chose to
use names which give some appropriate functionality for each package.

Regards.

                  - Thomas

-- 
Thomas Lockhart				lockhart@alumni.caltech.edu
South Pasadena, California

  16. Re: [HACKERS] rpms

    Lamar Owen <lamar.owen@wgcr.org> — 2000-03-01T17:01:18Z

    Thomas Lockhart wrote:
> Anyway, afaik most RPM distros of a product have one .rpm file which
> has the name of the package, and then may have other .rpm files which
> have qualifiers, like "-server". So in choosing which .rpm file will
> be the base package, it seemed most appropriate that it be the
> client-side stuff, as opposed to docs, or server (which btw can't
> really be run on its own without the client stuff installed
> *somewhere*), or something else.
 
> I appreciate your points, but it isn't clear to me how to eliminate
> *all* possibilities for confusion via RPM package names, so chose to
> use names which give some appropriate functionality for each package.

Thanks for fielding this, Thomas.  While it is certainly possible to
have a set of subpackages without a 'main' package (the Amanda network
backup package comes to mind), I personally agree with you.  Besides,
the comments for the postgresql-x.x.x-x.i386.rpm package states that it
contains only the clients and docs -- or at least I think it does :-).

And there will always be confusion with as many packages as we have. 
The only alternative that I see is to integrate all the packages into
one -- and that is by far a worse solution, as it requires way too many
packages installed -- it should not be necessary to have X installed to
run a postgresql server, for instance -- only the tk client and pgaccess
require X.

--
Lamar Owen
WGCR Internet Radio
1 Peter 4:11

  17. Re: [HACKERS] having and union in v7beta

    Tom Lane <tgl@sss.pgh.pa.us> — 2000-03-01T17:50:12Z

    >>>>> But it's tough to believe that that accounts for a 3-to-4x
>>>>> slowdown of this query; certainly I don't see much performance
>>>>> difference on the datatypes I tried.  What datatypes are your fields,
>>>>> anyway?
>> 
>>>> 6.5 takes 0.463s
>>>> 7.0 takes 1.640s
>>>> the field type is CHAR(4)
>> 
>> Hmm.  I see no more than a few percent difference between 6.5 and
>> current.  There's something peculiar going on on your system.

I compiled up current code with profiling enabled (make PROFILE=-pg
if you want to try it), and found that actually nearly all of the
runtime for
	select * from comuni union select * from comuni
is spent in the sort step; so I was on the wrong track in guessing
that there might be a performance problem in the new Unique coding.

I am not sure why you're seeing a performance differential for sorting.
Most of the cycles are going to go into bpcharlt(), which ultimately
calls strcoll() if you have USE_LOCALE defined.  That's probably not a
very fast operation, but that code's hardly changed at all since 6.5.
It should be the same speed...

Are you sure you compiled both 6.5 and 7.0 the same way (with or without
USE_LOCALE)?  Are you sure they're both running under the same locale
setting?

You might also try running the sort entirely in memory (no temp files).
Starting psql with
	setenv PGOPTIONS "-S 10000"
(10 meg sort space) should do it.  I'd be interested to know how 6.5
and 7.0 stack up for you that way.

			regards, tom lane

  18. Re: [HACKERS] having and union in v7beta

    Tom Lane <tgl@sss.pgh.pa.us> — 2000-03-01T19:06:47Z

    I wrote:
> I compiled up current code with profiling enabled (make PROFILE=-pg
> if you want to try it), and found that actually nearly all of the
> runtime for
> 	select * from comuni union select * from comuni
> is spent in the sort step; so I was on the wrong track in guessing
> that there might be a performance problem in the new Unique coding.

Wait a second.  Stop the presses.  I see what's going on here.

6.5.*:
play=> explain select * from comuni union select * from comuni;
NOTICE:  QUERY PLAN:

Seq Scan on comuni  (cost=512.00 rows=10000 width=84)

7.0beta1:
regression=# explain select * from comuni union select * from comuni;
NOTICE:  QUERY PLAN:

Unique  (cost=149.66..184.66 rows=200 width=84)
  ->  Sort  (cost=149.66..149.66 rows=2000 width=84)
        ->  Append  (cost=0.00..40.00 rows=2000 width=84)
                ->  Seq Scan on comuni  (cost=0.00..20.00 rows=1000 width=84)
                ->  Seq Scan on comuni  (cost=0.00..20.00 rows=1000 width=84)


7.0beta1's behavior is actually "correct", in the sense that it yields
the SQL-approved result: the UNION implies a DISTINCT pass over its
result, according to SQL, and 7.0beta1 is giving you a DISTINCT result.
6.5 is failing to generate the DISTINCT operation, because it
incorrectly simplifies "select foo union select foo" into "select foo"
if the two select queries are identical.  (There is a TODO item for this.)
So that's why 6.5 is a lot faster.  But it gives the wrong answer.

*However*, we have not fixed the bug that causes "select foo union
select foo" to be incorrectly simplified --- the UNION code is still
applying cnfify.  (Which it probably shouldn't, but I haven't wanted
to touch that code until I have the time to rewrite it completely.)
The reason 7.0beta1 generates the "right" answer is that it has a
recently-introduced bug in the comparison routines that causes it to
think the two select subqueries aren't the same.

I just fixed that bug, with the result that current CVS code is now back
to mis-simplifying this query.  (Yes, this is a step forward --- that
bug could have caused the system to unify two queries that AREN'T the
same, which would definitely be a bad thing...)

So, thanks!  You did indeed identify a bug!  But you should expect that
this query *will* get slower when we fix the other bug ;-).  You should
use a less silly test case for UNION if you want to make realistic
performance comparisons across versions.

			regards, tom lane

  19. Re: [HACKERS] rpms

    Peter Eisentraut <e99re41@docs.uu.se> — 2000-03-02T15:58:42Z

    On Wed, 1 Mar 2000, Thomas Lockhart wrote:

> Anyway, afaik most RPM distros of a product have one .rpm file which
> has the name of the package, and then may have other .rpm files which
> have qualifiers, like "-server". So in choosing which .rpm file will
> be the base package, it seemed most appropriate that it be the
> client-side stuff, as opposed to docs, or server (which btw can't
> really be run on its own without the client stuff installed
> *somewhere*), or something else.

Usually, the "base" package somehow contains what the package centers
around and the -xxx packages are supplements (like -headers, -devel,
-foointerface). Arguably, PostgreSQL centers around the database server.

Why not just name the packages postgresql-server and postgresql-client and
have no 'postgresql' as such. That should alleviate any confusion
whatsoever.


-- 
Peter Eisentraut                  Sernanders väg 10:115
peter_e@gmx.net                   75262 Uppsala
http://yi.org/peter-e/            Sweden

  20. Re: [HACKERS] rpms

    Thomas Lockhart <lockhart@alumni.caltech.edu> — 2000-03-02T16:38:23Z

    > Why not just name the packages postgresql-server and postgresql-client and
> have no 'postgresql' as such. That should alleviate any confusion
> whatsoever.

That is possible. imho it is solving a "problem" with no clear benefit
in the end, so why bother? Just renaming packages doesn't, by name
alone, clarify which packages depend on others, doesn't clarify that
-server depends on -client, etc etc.

I'd recommend going with the current scheme for some more time, and
rather put the effort into clarifying in docs what the packages are
and which are useful for what. I'm pretty sure that Lamar has some of
this in place already, and we can see about integrating some of the
info for v7.0 docs...

                     - Thomas

-- 
Thomas Lockhart				lockhart@alumni.caltech.edu
South Pasadena, California

  21. Re: [HACKERS] rpms

    Sergio A. Kessler <sak@tribctas.gba.gov.ar> — 2000-03-03T12:39:32Z

    Thomas Lockhart <lockhart@alumni.caltech.edu> el día Thu, 02 Mar 2000 
16:38:23 +0000, escribió:

>> Why not just name the packages postgresql-server and postgresql-client
[...]
>That is possible. imho it is solving a "problem" with no clear benefit
>in the end, so why bother? Just renaming packages doesn't, by name
>alone, clarify which packages depend on others, doesn't clarify that
>-server depends on -client, etc etc.

sorry to be picky thomas, but if the name has almost no mean
(as you imply) then why not call the package "pirindonga" ?

anyway, is not a problem for =me=, I know now what the package
contains (but I've installed the postgres rpm believing I was
installing the server, so count on me as one damnified that
ignored that there must be a package named just postgresql).

one last thing, usually users don't look at the full description
of the package before installing it, they (and I) just do
rpm -Uvh xxxxx.rpm (usually the name is self descriptive)

sergio

  22. Re: [HACKERS] rpms

    Henry B. Hotz <hotz@jpl.nasa.gov> — 2000-03-03T18:58:19Z

    At 4:39 AM -0800 3/3/00, Sergio A. Kessler wrote:
>Thomas Lockhart <lockhart@alumni.caltech.edu> el día Thu, 02 Mar 2000
>16:38:23 +0000, escribió:
>
>>> Why not just name the packages postgresql-server and postgresql-client
>[...]
>>That is possible. imho it is solving a "problem" with no clear benefit
>>in the end, so why bother? Just renaming packages doesn't, by name
>>alone, clarify which packages depend on others, doesn't clarify that
>>-server depends on -client, etc etc.
>
>sorry to be picky thomas, but if the name has almost no mean
>(as you imply) then why not call the package "pirindonga" ?

I live in NetBSD-land where the package system must be a bit different.
(It's based on FreeBSD ports.)  You can do a pkg_info and get a nice, short
summary of the package contents including the dependencies.  For example
TeX comes in about 5 packages and it wasn't at all hard for me to figure
out that I needed all but one of them.  If you install the package it will
automatically install any packages it depends on.  Dependencies can be
wild-carded so a package will accept a prerequisite package that is newer
than required and so on.

Do I take it that RedHat packages are not this nice?  Or is there some
subtlety to this discussion I'm missing?  Isn't there some convention for
how these things are handled already?

Signature failed Preliminary Design Review.
Feasibility of a new signature is currently being evaluated.
h.b.hotz@jpl.nasa.gov, or hbhotz@oxy.edu

  23. Re: [HACKERS] rpms

    Lamar Owen <lamar.owen@wgcr.org> — 2000-03-03T20:46:05Z

    "Henry B. Hotz" wrote:
> Do I take it that RedHat packages are not this nice?  Or is there some
> subtlety to this discussion I'm missing?  Isn't there some convention for
> how these things are handled already?

rpm -qi postgresql

--
Lamar Owen
WGCR Internet Radio
1 Peter 4:11

  24. Re: [HACKERS] rpms

    Fernando Magari1os Lamas <fml@lulu.styx.net> — 2000-03-04T00:42:46Z

    >sorry to be picky thomas, but if the name has almost no mean
>(as you imply) then why not call the package "pirindonga" ?

That one would certainly be a popular name in Mxico ;-)

>anyway, is not a problem for =me=, I know now what the package
>contains (but I've installed the postgres rpm believing I was
>installing the server, so count on me as one damnified that
>ignored that there must be a package named just postgresql).
>
>one last thing, usually users don't look at the full description
>of the package before installing it, they (and I) just do
>rpm -Uvh xxxxx.rpm (usually the name is self descriptive)

Most of the final users just use the regular distributions, so the
name could only matter to the packager. And even when you upgrade
you'll just do a rpm -Uh postgr*

Just my two cents...