On Wed, 2003-01-15 at 20:15, Tom Lane wrote:
> Rod Taylor <[EMAIL PROTECTED]> writes:
> > On Wed, 2003-01-15 at 16:07, Tom Lane wrote:
> >> Hm. I just finished verifying that CVS tip builds and passes cleanly
> >> on both HPUX and Linux (Red Hat 8.0). So either you've got a build
> >> error (did
> >> Hm. I just finished verifying that CVS tip builds and passes cleanly
> >> on both HPUX and Linux (Red Hat 8.0). So either you've got a build
> >> error (did you do a "make clean" after your last update?) or there's
> >> some really weird platform dependency involved. What's your platform
>
Rod Taylor <[EMAIL PROTECTED]> writes:
> On Wed, 2003-01-15 at 16:07, Tom Lane wrote:
>> Hm. I just finished verifying that CVS tip builds and passes cleanly
>> on both HPUX and Linux (Red Hat 8.0). So either you've got a build
>> error (did you do a "make clean" after your last update?) or there
On Wed, 2003-01-15 at 16:07, Tom Lane wrote:
> Rod Taylor <[EMAIL PROTECTED]> writes:
> > Last update was about 5 minutes after Bruce's header fix went into
> > place.
> Hm. I just finished verifying that CVS tip builds and passes cleanly
> on both HPUX and Linux (Red Hat 8.0). So either you've
Rod Taylor <[EMAIL PROTECTED]> writes:
> Last update was about 5 minutes after Bruce's header fix went into
> place.
Hm. I just finished verifying that CVS tip builds and passes cleanly
on both HPUX and Linux (Red Hat 8.0). So either you've got a build
error (did you do a "make clean" after your
Rod Taylor <[EMAIL PROTECTED]> writes:
> Index Scan using inet_idx1 on inet_tbl (cost=3D0.00..4.68 rows=3D7
> width=3D64)
>Index Cond: ((i > '192.168.1.0/24'::inet) AND (i <=3D
> '192.168.1.255'::inet))
>Filter: (i << '192.168.1.0/24'::inet)
> (3 rows)
That's the expected plan ...
> reg
Rod Taylor <[EMAIL PROTECTED]> writes:
> With Bruce's patch came a few others -- plus a recompile with all
> updates.
Which patch exactly? The regression test was still passing for me
as of yesterday's sources plus the large planner commit I just made.
I'm resyncing to CVS tip at the moment ...
On Wed, 2003-01-15 at 15:29, Tom Lane wrote:
> Rod Taylor <[EMAIL PROTECTED]> writes:
> > With Bruce's patch came a few others -- plus a recompile with all
> > updates.
>
> Which patch exactly? The regression test was still passing for me
> as of yesterday's sources plus the large planner commit
With Bruce's patch came a few others -- plus a recompile with all
updates.
> ... and that's the expected result. So why'd you get a different result
> while running the regression test? Curiouser and curiouser...
--
Rod Taylor <[EMAIL PROTECTED]>
PGP Key: http://www.rbt.ca/rbtpub.asc
signat
regression=#
regression=#
regression=# create index inet_idx1 on inet_tbl(i);
CREATE INDEX
regression=# set enable_seqscan to off;
SET
regression=# explain select * from inet_tbl where
i<<'192.168.1.0/24'::cidr;
QUERY
PLAN
-
If you get it working, I can remove the ORDER BY's I added.
---
Tom Lane wrote:
> Rod Taylor <[EMAIL PROTECTED]> writes:
> > Looks like some ORDER BY statements would be useful.
>
> To do what? Those queries should already
Rod Taylor <[EMAIL PROTECTED]> writes:
> Looks like some ORDER BY statements would be useful.
To do what? Those queries should already be producing indexscan plans.
If you're not getting the expected answers, there is something that
needs to be fixed, not papered over.
Please try
create index i
OK, I have applied an patch to ORDER BY on those queries. I don't see
the ordering you have here, but this should fix it for you. I also
uppercased the keywords while I was in there.
---
Rod Taylor wrote:
-- Start of PGP si
Looks like some ORDER BY statements would be useful.
*** ./expected/inet.out Sat Jun 16 22:05:20 2001
--- ./results/inet.out Wed Jan 15 10:18:40 2003
***
*** 193,212
select * from inet_tbl where i<<'192.168.1.0/24'::cidr;
c|i
14 matches
Mail list logo
