From: | The Hermit Hacker <scrappy(at)hub(dot)org> |
---|---|
To: | Jan Vicherek <honza(at)ied(dot)com> |
Cc: | Hannu Krosing <hannu(at)trust(dot)ee>, pgsql-hackers(at)postgreSQL(dot)org, vadim(at)sable(dot)krasnoyarsk(dot)su |
Subject: | Re: Browsing the tables / why pgsql does not perform well (with temp fix) |
Date: | 1998-01-25 03:55:38 |
Message-ID: | Pine.BSF.3.96.980124235139.28536A-100000@thelab.hub.org |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | 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(at)hub(dot)org secondary: scrappy(at){freebsd|postgresql}.org
From | Date | Subject | |
---|---|---|---|
Next Message | Jan Vicherek | 1998-01-25 04:12:49 | Re: Browsing the tables / why pgsql does not perform well (with temp fix) |
Previous Message | The Hermit Hacker | 1998-01-25 03:50:38 | Re: [HACKERS] Re: Copyright question: GPL patches for non-GPL packages (fwd) |