Re: Re: Postgres slowdown on large table joins
От | Dave Edmondson |
---|---|
Тема | Re: Re: Postgres slowdown on large table joins |
Дата | |
Msg-id | 20010220134624.A73384@verdi.jlc.net обсуждение исходный текст |
Ответ на | Re: Re: Postgres slowdown on large table joins (Larry Rosenman <ler@lerctr.org>) |
Список | pgsql-general |
On Mon, Feb 19, 2001 at 08:34:47PM -0600, Larry Rosenman wrote: > * Dave Edmondson <david@jlc.net> [010219 14:40]: > > > > yes. I ran VACUUM ANALYZE after creating the indicies. (Actually, I VACUUM > > > > the database twice a day.) The data table literally has 145972 rows, and > > > > 145971 will match conf_id 4... > > > > > > Hm. In that case the seqscan on data looks pretty reasonable ... not > > > sure if you can improve on this much, except by restructuring the tables. > > > How many rows does the query actually produce, anyway? It might be that > > > most of the time is going into sorting and delivering the result rows. > > > > All I'm really trying to get is the latest row with a conf_id of 4... I'm > > not sure if there's an easier way to do this, but it seems a bit ridiculous > > to read in almost 146000 rows to return 1. :( > > is there a timestamp or date/time tuple in the row? If so, index > THAT. > > LER actually, just did that yesterday... now that I finally understand incides. Thanks anyway. -- David Edmondson <david@jlc.net> GMU/FA d-(--) s+: a18>? C++++$ UB++++$ P+>+++++ L- E--- W++ N- o K-> w-- O? M-(--) V? PS+ PE+ Y? PGP t 5 X R+ tv-->! b DI+++ D+ G(--) e>* h!>+ r++ y+>++ ICQ: 79043921 AIM: AbsintheXL #music,#hellven on irc.esper.net
В списке pgsql-general по дате отправления: