Re: [BUGS] Bug #477: path ?# path
[EMAIL PROTECTED] writes: > the ?# (geometric intersection) operator for paths iterates over point > pairs in each path testing for intersection. however, it ignores the > last->first point pair for closed paths. Looks like a bug to me too; and path_distance, path_length, dist_ppath also fail to consider the closing segment of a closed path. Fixed for 7.2. regards, tom lane ---(end of broadcast)--- TIP 5: Have you checked our extensive FAQ? http://www.postgresql.org/users-lounge/docs/faq.html
Infinity confuses planner (was Re: [BUGS] query plan)
"Mike Quinn" <[EMAIL PROTECTED]> writes: [ query behaves okay as WHERE Crops.change_e > '10/1/2001' but not as WHERE '10/1/2001' < Crops.change_e ] Ah-hah, I see it. The critical factor is that you have some +infinity values in that timestamp column, so that the column data range recorded by VACUUM ANALYZE is some-finite-value to +infinity. When scalarltsel tries to estimate the fraction of rows that this WHERE clause matches, it does denominator = high - low; if (flag & SEL_RIGHT) numerator = val - low; else numerator = high - val; result = numerator / denominator; which in one case computes infinity/infinity (yielding NAN) and in the other case computes some-finite-value/infinity (yielding zero). So we get a NAN for the selectivity and then all the subsequent computations in the planner are infected with NANs, leading it to select some random plan or other as the "cheapest". The reason I didn't see it here is that on my platform, the infinity timestamp values aren't represented as real IEEE infinities, and so the result isn't NAN. Seems like we could fix this either by forbidding use of real infinity for timestamp and float8 values ... probably not workable for float8, even if it's okay for timestamp ... or by trying to defend against infinity and NAN results in the selectivity subroutines. Comments anyone? regards, tom lane ---(end of broadcast)--- TIP 3: if posting/reading through Usenet, please send an appropriate subscribe-nomail command to [EMAIL PROTECTED] so that your message can get through to the mailing list cleanly
Re: [BUGS] ecpg - GRANT bug
Your patch has been added to the PostgreSQL unapplied patches list at:
http://candle.pha.pa.us/cgi-bin/pgpatches
I will try to apply it within the next 48 hours.
---
> I've noticed general buggyness with ecpg on one of my source files for
> a while now but it only got really annoying after setting up overnight
> build on Linux (output corrupt code), Solaris (output correct code),
> AIX (crashed) and HPUX (crashed).
>
> After comparing the output from ecpg on Linux and Solaris the
> following type of statement was the root of the crash:
>
> EXEC SQL GRANT ALL ON exampletable TO PUBLIC;
>
> When the parser code was rebuilding the query to pass onto the server
> it was trying to include an extra, non-existent, parameter...
>
> The bug is present in 7.1.2, 7.1.3 and the current CVS sources. The
> following patch (against CVS version) corrects this bug:
>
> ./interfaces/ecpg/preproc/preproc.y
> *** ./interfaces/ecpg/preproc/preproc.y.orig Fri Oct 12 16:22:05 2001
> --- ./interfaces/ecpg/preproc/preproc.y Fri Oct 12 16:22:09 2001
> ***
> *** 1693,1699
>
> GrantStmt: GRANT privileges ON opt_table relation_name_list TO grantee_list
>opt_with_grant
> {
> ! $$ = cat_str(8, make_str("grant"), $2,
>make_str("on"), $4, $5, make_str("to"), $7);
> }
> ;
>
> --- 1693,1699
>
> GrantStmt: GRANT privileges ON opt_table relation_name_list TO grantee_list
>opt_with_grant
> {
> ! $$ = cat_str(7, make_str("grant"), $2,
>make_str("on"), $4, $5, make_str("to"), $7);
> }
> ;
>
> ---(end of broadcast)---
> TIP 2: you can get off all lists at once with the unregister command
> (send "unregister YourEmailAddressHere" to [EMAIL PROTECTED])
>
--
Bruce Momjian| http://candle.pha.pa.us
[EMAIL PROTECTED] | (610) 853-3000
+ If your life is a hard drive, | 830 Blythe Avenue
+ Christ can be your backup.| Drexel Hill, Pennsylvania 19026
---(end of broadcast)---
TIP 3: if posting/reading through Usenet, please send an appropriate
subscribe-nomail command to [EMAIL PROTECTED] so that your
message can get through to the mailing list cleanly
Re: Infinity confuses planner (was Re: [BUGS] query plan)
Bruce Momjian <[EMAIL PROTECTED]> writes: > Shouldn't infinity be treated similar to NULL. Nope. It has a definite position in the sort order. regards, tom lane ---(end of broadcast)--- TIP 4: Don't 'kill -9' the postmaster
Re: Infinity confuses planner (was Re: [BUGS] query plan)
> The reason I didn't see it here is that on my platform, the infinity > timestamp values aren't represented as real IEEE infinities, and so the > result isn't NAN. > > Seems like we could fix this either by forbidding use of real infinity > for timestamp and float8 values ... probably not workable for float8, > even if it's okay for timestamp ... or by trying to defend against > infinity and NAN results in the selectivity subroutines. Shouldn't infinity be treated similar to NULL. I know they are different but they are clearly off-the-scale type values. The problem is that it is type-specific and not general enough for the optimizer. Tough one. -- Bruce Momjian| http://candle.pha.pa.us [EMAIL PROTECTED] | (610) 853-3000 + If your life is a hard drive, | 830 Blythe Avenue + Christ can be your backup.| Drexel Hill, Pennsylvania 19026 ---(end of broadcast)--- TIP 3: if posting/reading through Usenet, please send an appropriate subscribe-nomail command to [EMAIL PROTECTED] so that your message can get through to the mailing list cleanly
Re: Infinity confuses planner (was Re: [BUGS] query plan)
> Bruce Momjian <[EMAIL PROTECTED]> writes: > > Shouldn't infinity be treated similar to NULL. > > Nope. It has a definite position in the sort order. I was thinking about the optimizer's histogram, not the index ordering. Anyway, seems you got it fixed already. -- Bruce Momjian| http://candle.pha.pa.us [EMAIL PROTECTED] | (610) 853-3000 + If your life is a hard drive, | 830 Blythe Avenue + Christ can be your backup.| Drexel Hill, Pennsylvania 19026 ---(end of broadcast)--- TIP 1: subscribe and unsubscribe commands go to [EMAIL PROTECTED]
