Re: mnogosearch -- pgsql seem so slow, please help me find out why
От | Thomas T. Thai |
---|---|
Тема | Re: mnogosearch -- pgsql seem so slow, please help me find out why |
Дата | |
Msg-id | Pine.NEB.4.21.0101121054570.18450-100000@ns01.minnesota.com обсуждение исходный текст |
Ответ на | Re: mnogosearch -- pgsql seem so slow, please help me find out why (Tom Lane <tgl@sss.pgh.pa.us>) |
Ответы |
Re: mnogosearch -- pgsql seem so slow, please help me find out why
Re: Re: mnogosearch -- pgsql seem so slow, please help me find out why |
Список | pgsql-general |
On Fri, 12 Jan 2001, Tom Lane wrote: > "Thomas T. Thai" <tom@minnesota.com> writes: > > 'select * from url' from psql monitor took 59 seconds. > > How big is the table? Your EXPLAIN mentions 99256 rows, but I can't > tell if that stat is up-to-date or not. it is 99256. i don't think it's that big of a table is it? typically the query under mnogo takes less than a second, at most a couple seconds but not 50+ secs. maybe Hermit has some input as he runs it for postgresql.org's search. > A select like that is going to be pretty much all data transfer: read > the disk blocks, format the data values, send 'em to the frontend. > There's hardly anything that Postgres can do to optimize or pessimize > it. You might shave a few milliseconds by using a binary cursor (to > avoid formatting the integer values into ASCII) but probably not a lot. > > If you've done a whole lot of UPDATEs/DELETEs on the table since your > last VACUUM, then reading empty disk blocks might be costing you some > time. i did vacuum analyze.
В списке pgsql-general по дате отправления: