2006/9/16, Gregory Stark <[EMAIL PROTECTED]>:
Alvaro Herrera <[EMAIL PROTECTED]> writes:
> I don't know if this is the same thing you are talking about, but Oleg
> talked to me on the conference about "partial sort", which AFAICS it's
> about the same thing you are talking about. I think Teodo
On Fri, Sep 15, 2006 at 10:06:16PM +0100, Gregory Stark wrote:
> > I'm curious, as I may be such an offender. What alternatives exist?
> > ...
> > What alternatives to limit/offset exist? If there are thousands or
> > more results, I have trouble with an idea that the entire results
> > should be q
Alvaro Herrera <[EMAIL PROTECTED]> writes:
> I don't know if this is the same thing you are talking about, but Oleg
> talked to me on the conference about "partial sort", which AFAICS it's
> about the same thing you are talking about. I think Teodor submitted a
> patch to implement it, which was
[EMAIL PROTECTED] writes:
> On Fri, Sep 15, 2006 at 08:22:50PM +0100, Gregory Stark wrote:
>
> I'm curious, as I may be such an offender. What alternatives exist?
>
> I think you mean the concept of showing a page of information that
> you can navigate forwards and backwards a page, or select a r
On Fri, Sep 15, 2006 at 08:22:50PM +0100, Gregory Stark wrote:
> But just in case it's not clear for anyone the usual use case for
> this paging results on a web page. As much as I normally try to
> convince people they don't want to do it that way they usually do
> end up with it implemented using
Martijn van Oosterhout writes:
> On Fri, Sep 15, 2006 at 05:30:27PM +0100, Gregory Stark wrote:
>> Also, because heap sort is slower than qsort (on average anyways) it makes
>> sense to not bother with the heap until the number of tuples grows well
>> beyond
>> the limit or until it would other
Gregory Stark wrote:
> Tom Lane <[EMAIL PROTECTED]> writes:
>
> > I believe a better way to think about this would be as an aggregate that
> > remembers the top N rows.
>
> Wouldn't such a thing just be a reimplementation of a tuplestore though? I
> mean, it's storing tuples you feed it, sortin
Tom Lane <[EMAIL PROTECTED]> writes:
> Gregory Stark <[EMAIL PROTECTED]> writes:
>
>> I think this is pretty important to cover at some point because really _not_
>> doing this just wrong.
>
> I can't get all *that* excited about it, since an index solves the
> problem.
Well I'm not all *that* ex
On Fri, Sep 15, 2006 at 05:30:27PM +0100, Gregory Stark wrote:
> Also, because heap sort is slower than qsort (on average anyways) it makes
> sense to not bother with the heap until the number of tuples grows well beyond
> the limit or until it would otherwise spill to disk.
The thought that comes
Tom Lane <[EMAIL PROTECTED]> writes:
> I believe a better way to think about this would be as an aggregate that
> remembers the top N rows.
Wouldn't such a thing just be a reimplementation of a tuplestore though? I
mean, it's storing tuples you feed it, sorting them, and spitting them back
out
Tom Lane wrote:
(unless we want to invent aggregates that can return SETOF?)
Doesn't sound like a bad idea at all ...
cheers
andrew
---(end of broadcast)---
TIP 6: explain analyze is your friend
Gregory Stark <[EMAIL PROTECTED]> writes:
> I've been looking at doing the following TODO item:
> Allow ORDER BY ... LIMIT # to select high/low value without sort or index
> using a sequential scan for highest/lowest values
> I think this is pretty important to cover at some point because
I've been looking at doing the following TODO item:
Allow ORDER BY ... LIMIT # to select high/low value without sort or index
using a sequential scan for highest/lowest values
Right now, if no index exists, ORDER BY ... LIMIT # requires we sort all
values to return the high/low v
13 matches
Mail list logo
