Обсуждение: Administration Wizards ...
Hello All, I was wondering if anyone would find a Wizard/GUI based administration tool useful. It would be similar to the System Adminstration Wizard facility in NT. I was planning to use Qt/KDE as the basis for the project. I was thinking of tasks like add/delete users, databases, dumps and the like. The interface would lead the user through the choosen task step by step. If you wanted a tool like this, what should it be able to do? Thanks in advance for your input. Regards, Keith Davis Mutiny Bay Software E-mail: keidav@mutinybaysoftware.com Web: http://www.mutinybaysoftware.com UNIX IS user friendly; it's just picky about who its friends are.
"Keith R. Davis" wrote: > > Hello All, > > I was wondering if anyone would find a Wizard/GUI based administration tool > useful. It would be similar to the System Adminstration Wizard facility in > NT. I was planning to use Qt/KDE as the basis for the project. > Keith, I haven't tried it but it may be worth having a look at the pgAdmin web page for some ideas. http://www.vale-it.demon.co.uk/freeware/pgadmin/features.html Steve Boyle Roselink Systems Limited email: boylesa@dial.pipex.com > I was thinking of tasks like add/delete users, databases, dumps and the > like. The interface would lead the user through the choosen task step by > step. > > If you wanted a tool like this, what should it be able to do? > > Thanks in advance for your input. > > Regards, > > Keith Davis > Mutiny Bay Software > > E-mail: keidav@mutinybaysoftware.com > Web: http://www.mutinybaysoftware.com > > UNIX IS user friendly; it's just picky about who its friends are.
Hey,
I'm having a very weird thing happening here.
I've had this one table for quite some time, but what I haven't noticed
until now is that only 3 out of 9 indexes seems to be working on it.
OS: Red Hat Linux 6.0 / Linux 2.2.6
Arch: i386
Postgres version: CVS of 6.5 a few days before actual release
Table = av_parts
+----------------------------------+----------------------------------+-------+
| Field | Type |Length|
+----------------------------------+----------------------------------+-------+
| itemid | int4 not null default nextval ( |4 |
| vendorid | int4 |4 |
| partnumber | varchar() |25 |
| alternatepartnumber | varchar() |25 |
| nsn | varchar() |15 |
| description | varchar() |50 |
| condition | varchar() |10 |
| quantity | int4 |4 |
| rawpartnumber | varchar() |25 |
| rawalternatenumber | varchar() |25 |
| rawnsnnumber | varchar() |15 |
| date | int4 |4 |
| cagecode | varchar() |10 |
+----------------------------------+----------------------------------+-------+
Indices: av_parts_altpartnum_index
av_parts_itemid_key
av_parts_nsn_index
av_parts_partnumber_index
av_parts_rawalternatenumber_ind
av_parts_rawaltnum_index
av_parts_rawnsn_index
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
av_parts_rawpartnumber_index
av_parts_vendorid_index
This is the one I will use as an example. This is an index on
rawnsnnumber (varchar 15).
Output of a simple select on that field:
parts=> explain select * from av_parts where rawnsnnumber = '123456';
NOTICE: QUERY PLAN:
Seq Scan on av_parts (cost=194841.86 rows=3206928 width=124)
EXPLAIN
This doesn't really make sense. There is an index on that field, and I
have just done a vacuum on the table.
The index on partnumber, itemid and vendorid is being used properly, all
others are not.
Can someone explain this?
Thanks,
Ole Gjerde
Hi, I'm still having this same problem. Below is a simple test to show the problem. Same table as before, but I removed all indices except the itemid field(serial). Thanks, Ole Gjerde parts=> create index av_parts_nsn_index on av_parts(nsn); CREATE parts=> explain select * from av_parts where nsn = '123456'; NOTICE: QUERY PLAN: Seq Scan on av_parts (cost=194841.86 rows=3206927 width=124) EXPLAIN parts=> vacuum verbose av_parts; NOTICE: --Relation av_parts-- NOTICE: Pages 63834: Changed 0, Reapped 0, Empty 0, New 0; Tup 3969935: Vac 0, Keep/VTL 0/0, Crash 0, UnUsed 0, MinLen 92, MaxLen 200; Re-using: Free/Avail. Space 0/0; EndEmpty/Avail. Pages 0/0. Elapsed 29/11 sec. NOTICE: Index av_parts_nsn_index: Pages 8705; Tuples 3969935. Elapsed 3/75 sec. NOTICE: Index av_parts_itemid_key: Pages 7818; Tuples 3969935. Elapsed 3/74 sec. VACUUM parts=> explain select * from av_parts where nsn = '123456'; NOTICE: QUERY PLAN: Seq Scan on av_parts (cost=194841.86 rows=3206927 width=124) EXPLAIN
Hey,
More info on the index problem.
I fixed the previous problem by doing a pg_upgrade and all that stuff.
Now explain actually says it's using indices and whatnot.
But now I'm having a different but related problem.
Now, If I do a select on one field, everything is all good and indices are
being used. But, if I try to add a "OR" in there, even on the same field,
explain says indices are being used, but query is taking forever 5min+
With the query below, if I take out either one of the statements in the
(stmt OR Stmt) it returns immediately. Top one returns 11 rows and
bottom one 20 rows.
The weird thing is, why is explain showing such a high cost for going
through the indices?
Both tables have been vacuumed(both normal and with analyze), so the
optimizer has completely up-to-date stats.
Thanks,
Ole Gjerde
Query with problem:
SELECT AV_Parts.PartNumber,
inventorysuppliers.companyname
FROM inventorysuppliers,
AV_Parts
WHERE (inventorysuppliers.id = AV_Parts.VendorID) AND
(
(AV_Parts.RawPartNumber LIKE '6890040%') OR
(AV_Parts.RawPartNumber LIKE '123456%')
);
explain output of query above:
NOTICE: QUERY PLAN:
Nested Loop (cost=183613.27 rows=12 width=32)
-> Index Scan using av_parts_rawpartnumber_index,
av_parts_rawpartnumber_index on av_parts (cost=183609.17 rows=2 width=16)
-> Index Scan using inventorysuppliers_id_index on inventorysuppliers
(cost=2.05 rows=210 width=16)
EXPLAIN