Thread: having and union in v7beta
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
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
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 psql7=# select count(*) from comuni;count ------- 8342 (1 row) 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) EXPLAIN psql65=> select count(*) from comuni;count ------- 8342 (1 row) psql65=> EXPLAIN select distretto from comuni union select codice_fiscale from comuni; NOTICE: QUERY PLAN: Unique (cost=848.57 rows=0 width=0) -> Sort (cost=848.57 rows=0 width=0) -> Append (cost=848.57 rows=0 width=0) -> Seq Scan on comuni (cost=424.29 rows=8342 width=12) -> Seq Scan on comuni (cost=424.29rows=8342 width=12) EXPLAIN
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
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
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 ============================================================================ POSTGRESQL BUG REPORTTEMPLATE ============================================================================ Your name : Jose' Soares Your email address : Jose@SferaCarta.com System Configuration --------------------- Architecture (example: Intel Pentium) : Intel Pentium Operating System (example: Linux 2.0.26 ELF) : Linux 2.0.37 Elf PostgreSQL version (example: PostgreSQL-6.1) : PostgreSQL-v7.0 Compiler used (example: gcc 2.7.2) : gcc 2.7.2.3 Please enter a FULL description of your problem: ------------------------------------------------ Seems that I found a bug on HAVING clause Please describe a way to repeat the problem. Please try to provide a concise reproducible example, if at all possible: ---------------------------------------------------------------------- I created a table like this one below: CREATE TABLE comuni (istat CHAR(06) PRIMARY KEY NOT NULL,nome CHAR(50) NOT NULL,provincia CHAR(02),codice_fiscale CHAR(04),cap CHAR(05),regione CHAR(03),distretto CHAR(04)); CREATE INDEX nome_comune_idx ON comuni (nome); 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. If you know how this problem might be fixed, list the solution below: --------------------------------------------------------------------- I don't know, but I can send you my table data if you want it.
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
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
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
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
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
> 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
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
"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
> >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
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
>>>>> 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 forselect * 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 withsetenv 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
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.00rows=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
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
> 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
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
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
"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
>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 M�xico ;-) >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...