Re: Browsing the tables / why pgsql does not perform well (with temp fix)
От | The Hermit Hacker |
---|---|
Тема | Re: Browsing the tables / why pgsql does not perform well (with temp fix) |
Дата | |
Msg-id | Pine.BSF.3.96.980124235139.28536A-100000@thelab.hub.org обсуждение исходный текст |
Ответ на | Re: Browsing the tables / why pgsql does not perform well (with temp fix) (Jan Vicherek <honza@ied.com>) |
Ответы |
Re: Browsing the tables / why pgsql does not perform well (with temp fix)
|
Список | pgsql-hackers |
On Sat, 24 Jan 1998, Jan Vicherek wrote: > On Sat, 24 Jan 1998, Hannu Krosing wrote: > > > > if aggregates were able to use indexes you could do: > > > > > > select min(n) from table where rowid >n; > > > > > > and then > > > > > > select * from table where n = n_found by_last_previous_select; > > > > > > but as they don't you would get very poor performance from the first > > > select; > > This looks good. No transactions necessary, no locking, no mutliple rows > copying. The SELECT above will create a READ lock on the table, preventing UPDATES from happening for the duration of the SELECT. There is *no* way of getting around or away from this lock... > > > So the real solution would be to use indexes for sorting, maybe at first > > > for single field sorts. > > How many hours would that take to write ? As Bruce said in another posting, he isn't even sure *where* to start on this, so I'd say over a month, if not longer...over a month in the sense that as of the end of this week, there will be no new developments on the source tree, only stabilization and bug fixes... Marc G. Fournier Systems Administrator @ hub.org primary: scrappy@hub.org secondary: scrappy@{freebsd|postgresql}.org
В списке pgsql-hackers по дате отправления: