"Tom Lane" <[EMAIL PROTECTED]> writes:
> Gregory Stark <[EMAIL PROTECTED]> writes:
>> "Tom Lane" <[EMAIL PROTECTED]> writes:
>>> Well, if you think it's easy, the best form of criticism is a patch.
>>> The change-of-direction problem seems to me to be messy --- not
>>> insoluble, but messy enough
Gregory Stark <[EMAIL PROTECTED]> writes:
> "Tom Lane" <[EMAIL PROTECTED]> writes:
>> Well, if you think it's easy, the best form of criticism is a patch.
>> The change-of-direction problem seems to me to be messy --- not
>> insoluble, but messy enough to need beta testing.
> Hm, I must have misun
"Tom Lane" <[EMAIL PROTECTED]> writes:
> Gregory Stark <[EMAIL PROTECTED]> writes:
>> "Tom Lane" <[EMAIL PROTECTED]> writes:
>>> ... I'm not even sure how to fix it (the nasty case is
>>> changing directions partway through the scan); let alone how to fix it in a
>>> way that's obviously enough r
Gregory Stark <[EMAIL PROTECTED]> writes:
> "Tom Lane" <[EMAIL PROTECTED]> writes:
>> ... I'm not even sure how to fix it (the nasty case is
>> changing directions partway through the scan); let alone how to fix it in a
>> way that's obviously enough right to make me feel comfortable in
>> back-pa
"Tom Lane" <[EMAIL PROTECTED]> writes:
> Gregory Stark <[EMAIL PROTECTED]> writes:
>> Hm, that has the nasty side effect that someone who uses SCROLL but doesn't
>> fetch backwards much or at all suddenly gets a much more expensive plan than
>> if they didn't.
>
> Well, what are they using SCROLL
Gregory Stark <[EMAIL PROTECTED]> writes:
> Hm, that has the nasty side effect that someone who uses SCROLL but doesn't
> fetch backwards much or at all suddenly gets a much more expensive plan than
> if they didn't.
Well, what are they using SCROLL for if they don't need it?
A more plausible obj
"Tom Lane" <[EMAIL PROTECTED]> writes:
> We could probably fix this by complicating the logic in ExecUnique,
> but I wonder whether it wouldn't be better to just stop treating
> Unique nodes as backwards-scannable. The only reason for that
> node type to exist (as opposed to using Group nodes) is
On Tue, 2008-08-05 at 18:00 -0500, Jaime Casanova wrote:
> On 8/5/08, Tom Lane <[EMAIL PROTECTED]> wrote:
> > Simon Riggs <[EMAIL PROTECTED]> writes:
> > > I've never seen anyone scan backwards like this at all in practical use.
> >
> > > I knew it was possible, but never seen it done.
> >
> > > I
On 8/5/08, Tom Lane <[EMAIL PROTECTED]> wrote:
> Simon Riggs <[EMAIL PROTECTED]> writes:
> > I've never seen anyone scan backwards like this at all in practical use.
>
> > I knew it was possible, but never seen it done.
>
> > It seems entirely probable nobody else has either. It's a PostgreSQL
> >
Simon Riggs <[EMAIL PROTECTED]> writes:
> I've never seen anyone scan backwards like this at all in practical use.
> I knew it was possible, but never seen it done.
> It seems entirely probable nobody else has either. It's a PostgreSQL
> extension, so people arriving from outside don't even know
On Tue, 2008-08-05 at 13:07 -0400, Tom Lane wrote:
> We could probably fix this by complicating the logic in ExecUnique,
> but I wonder whether it wouldn't be better to just stop treating
> Unique nodes as backwards-scannable.
No problem there.
> The only reason for that
> node type to exist
In the regression database:
regression=# select distinct on (ten) ten, thousand from tenk1 order by ten,
thousand;
ten | thousand
-+--
0 |0
1 |1
2 |2
3 |3
4 |4
5 |5
6 |6
7 |7
8 |8
9
12 matches
Mail list logo
