From: | Jean-Paul ARGUDO <jean-paul(dot)argudo(at)IDEALX(dot)com> |
---|---|
To: | Hackers <pgsql-hackers(at)postgresql(dot)org> |
Subject: | Re: contrib idea |
Date: | 2001-12-21 09:12:59 |
Message-ID: | 20011221091258.GB1938@pastis |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
> Keep in mind that the penalty for no index is a sequential scan, which
> _usually_ is a light operation. In fact, many queryes don't even use
> indexes if they are going to need to see more than a small portion of
> the table.
I agree...
Managing customers'DBs for years now, I'm convinced that systematic indexes are
good only for the intellect of the DBA because it may respect some methods :-)
Too many tables with less than thousands records. Automatic indexes are
annoying, I have to drop em all every time. It's harder to think in droping
unwanted indexes than creating wanted ones.
I know DBAs that drop automatic PK index created by PG only because the naming
method choosen for index is not like they want.. :-)
Table scans are always good idea for litle tables. Even more if the table is
fully cached (I dream of a "CREATE TABLE... CACHE"). Cool too when we'll be
able to store execution plans :-)
Finaly, there would be tables with more index than data :-) if you consider
tables with many FK. Where's the gain then?
Best regards,
--
Jean-Paul ARGUDO IDEALX S.A.S
Consultant bases de données 15-17, av. de Ségur
http://IDEALX.com/ F-75007 PARIS
From | Date | Subject | |
---|---|---|---|
Next Message | Hannu Krosing | 2001-12-21 12:21:12 | Re: 7.2 is slow? |
Previous Message | Marko Kreen | 2001-12-21 08:34:45 | Re: pgcryto failures on freebsd/alpha |