Re: [HACKERS] cvsup binaries?
Tom Lane wrote: Neil Conway [EMAIL PROTECTED] writes: The PostgreSQL docs suggest that ftp.postgresql.org holds binary builds of CVSup: Is this still the case? (I couldn't see any cvsup binaries, but perhaps they are well-hidden). If they are still there, they're probably exceedingly out of date :-( Although listed as RH9, the ones at http://www.joeconway.com/ work on my FC2 machine. They don't work on FC3 however, and I haven't gotten around to trying to rebuild on FC3. Joe ---(end of broadcast)--- TIP 8: explain analyze is your friend
Re: [HACKERS] cvsup binaries?
Joe Conway said: Tom Lane wrote: Neil Conway [EMAIL PROTECTED] writes: The PostgreSQL docs suggest that ftp.postgresql.org holds binary builds of CVSup: Is this still the case? (I couldn't see any cvsup binaries, but perhaps they are well-hidden). If they are still there, they're probably exceedingly out of date :-( Although listed as RH9, the ones at http://www.joeconway.com/ work on my FC2 machine. They don't work on FC3 however, and I haven't gotten around to trying to rebuild on FC3. Or look for FC3 RPMs in Fedora Extras for i386 and ppc (but not x86_64). cheers andrew ---(end of broadcast)--- TIP 2: you can get off all lists at once with the unregister command (send unregister YourEmailAddressHere to [EMAIL PROTECTED])
Re: [HACKERS] cvsup binaries?
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Hi, On Sat, 12 Mar 2005, Joe Conway wrote: Tom Lane wrote: Neil Conway [EMAIL PROTECTED] writes: The PostgreSQL docs suggest that ftp.postgresql.org holds binary builds of CVSup: Is this still the case? (I couldn't see any cvsup binaries, but perhaps they are well-hidden). If they are still there, they're probably exceedingly out of date :-( Although listed as RH9, the ones at http://www.joeconway.com/ work on my FC2 machine. They don't work on FC3 however, and I haven't gotten around to trying to rebuild on FC3. If anyone's interested, I've rebuilt the packages for RHEL ES 3: http://www.gunduz.org/rpms/cvsup/ Regards, - -- Devrim GUNDUZ devrim~gunduz.org, devrim~PostgreSQL.org, devrim.gunduz~linux.org.tr http://www.tdmsoft.com http://www.gunduz.org -BEGIN PGP SIGNATURE- Version: GnuPG v1.2.1 (GNU/Linux) iD8DBQFCMvyWtl86P3SPfQ4RAl+9AKDJ6kL21t+f+Kehz8CVGcdrQokLwACfaB2r ShLh063uyOHiuY35wpTIBG4= =OzRi -END PGP SIGNATURE- ---(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: [HACKERS] cvsup binaries?
Devrim GUNDUZ wrote: On Sat, 12 Mar 2005, Joe Conway wrote: Although listed as RH9, the ones at http://www.joeconway.com/ work on my FC2 machine. They don't work on FC3 however, and I haven't gotten around to trying to rebuild on FC3. If anyone's interested, I've rebuilt the packages for RHEL ES 3: http://www.gunduz.org/rpms/cvsup/ I just posted some FC3 i386 packages. Joe ---(end of broadcast)--- TIP 8: explain analyze is your friend
Re: [pgsql-hackers-win32] [HACKERS] snprintf causes regression tests to fail
Resubmission of yesterday's patch so that it would
cont conflict with Bruce's cvs commit. Pleas apply.
Best regards,
Nicolai.
On Sat, 12 Mar 2005 01:58:15 +0200, Nicolai Tufar [EMAIL PROTECTED] wrote:
On Thu, 10 Mar 2005 19:21:41 -0500 (EST), Bruce Momjian
pgman@candle.pha.pa.us wrote:
The CVS-tip implementation is fundamentally broken and won't work even
for our internal uses. I've not wasted time complaining about it
because I thought we were going to replace it. If we can't find a
usable replacement then we're going to have to put a lot of effort
into fixing what's there. On the whole I think the effort would be
better spent importing someone else's solution.
Oh, so our existing implementation doesn't even meet our needs. OK.
Which made me wander why did I not aggree with
Tom Lane's suggestion to make do three passes
instead of two. Tom was right, as usual. It happened to
be much easier than I expected. The patch is attached.
Please apply.
Tom, what do you think? Will it be fine with you?
Best regards,
Nicolai
*** ./src/port/snprintf.c.orig Sat Mar 12 09:13:43 2005
--- ./src/port/snprintf.c Sat Mar 12 10:01:44 2005
***
*** 195,200
--- 195,202
int pointflag;
char func;
int realpos;
+ int longflag;
+ int longlongflag;
} *fmtpar, **fmtparptr;
/* Create enough structures to hold all arguments */
***
*** 264,275
--- 266,279
realpos = position;
len = 0;
goto nextch;
+ /*
case '*':
if (pointflag)
maxwidth = va_arg(args, int);
else
len = va_arg(args, int);
goto nextch;
+ */
case '.':
pointflag = 1;
goto nextch;
***
*** 301,316
#endif
case 'u':
case 'U':
! /* fmtnum(value,base,dosign,ljust,len,zpad,output) */
! if (longflag)
! {
! if (longlongflag)
! value = va_arg(args, uint64);
! else
! value = va_arg(args, unsigned long);
! }
! else
! value = va_arg(args, unsigned int);
fmtpar[fmtpos].fmtbegin = fmtbegin;
fmtpar[fmtpos].fmtend = format;
fmtpar[fmtpos].numvalue = value;
--- 305,312
#endif
case 'u':
case 'U':
! fmtpar[fmtpos].longflag = longflag;
! fmtpar[fmtpos].longlongflag = longlongflag;
fmtpar[fmtpos].fmtbegin = fmtbegin;
fmtpar[fmtpos].fmtend = format;
fmtpar[fmtpos].numvalue = value;
***
*** 325,340
break;
case 'o':
case 'O':
! /* fmtnum(value,base,dosign,ljust,len,zpad,output) */
! if (longflag)
! {
! if (longlongflag)
! value = va_arg(args, uint64);
! else
! value = va_arg(args, unsigned long);
! }
! else
! value = va_arg(args, unsigned int);
fmtpar[fmtpos].fmtbegin = fmtbegin;
fmtpar[fmtpos].fmtend = format;
fmtpar[fmtpos].numvalue = value;
--- 321,328
break;
case 'o':
case 'O':
! fmtpar[fmtpos].longflag = longflag;
! fmtpar[fmtpos].longlongflag = longlongflag;
fmtpar[fmtpos].fmtbegin = fmtbegin;
fmtpar[fmtpos].fmtend = format;
fmtpar[fmtpos].numvalue = value;
***
*** 349,365
break;
case 'd':
case 'D':
! if (longflag)
! {
! if (longlongflag)
! {
! value = va_arg(args, int64);
! }
! else
! value = va_arg(args, long);
! }
! else
! value = va_arg(args, int);
fmtpar[fmtpos].fmtbegin = fmtbegin;
fmtpar[fmtpos].fmtend = format;
fmtpar[fmtpos].numvalue = value;
--- 337,344
break;
case 'd':
case 'D':
! fmtpar[fmtpos].longflag = longflag;
! fmtpar[fmtpos].longlongflag = longlongflag;
fmtpar[fmtpos].fmtbegin = fmtbegin;
fmtpar[fmtpos].fmtend = format;
fmtpar[fmtpos].numvalue = value;
***
*** 373,387
fmtpos++;
break;
case 'x':
! if (longflag)
! {
! if (longlongflag)
! value = va_arg(args, uint64);
! else
! value = va_arg(args, unsigned long);
! }
! else
! value = va_arg(args, unsigned int);
fmtpar[fmtpos].fmtbegin = fmtbegin;
fmtpar[fmtpos].fmtend = format;
fmtpar[fmtpos].numvalue = value;
--- 352,359
fmtpos++;
break;
case 'x':
! fmtpar[fmtpos].longflag = longflag;
! fmtpar[fmtpos].longlongflag = longlongflag;
fmtpar[fmtpos].fmtbegin = fmtbegin;
fmtpar[fmtpos].fmtend = format;
fmtpar[fmtpos].numvalue = value;
***
*** 395,409
fmtpos++;
break;
case 'X':
! if (longflag)
! {
! if (longlongflag)
! value = va_arg(args, uint64);
! else
! value = va_arg(args, unsigned long);
!
[HACKERS] REL8_0_STABLE and 8.0.1 release client logging difference
Hi there, I noticed client error logging was changed in REL8_0_STABLE in compare with 8.0.1 release. 8.0.1: tycho=# select * from pg_stas where srelnae='tycho'; ERROR: relation pg_stas does not exist tycho=# \q REL8_0_STABLE: tycho=# select * from pg_stas where srelnae='tycho'; tycho=# \q ostgresql.conf was the same. Regards, Oleg _ Oleg Bartunov, sci.researcher, hostmaster of AstroNet, Sternberg Astronomical Institute, Moscow University (Russia) Internet: oleg@sai.msu.su, http://www.sai.msu.su/~megera/ phone: +007(095)939-16-83, +007(095)939-23-83 ---(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: [HACKERS] TODO item: support triggers on columns
On Friday 11 March 2005 12:18, Bruce Momjian wrote:
Alvaro Herrera wrote:
On Fri, Mar 11, 2005 at 11:32:04AM -0500, Bruce Momjian wrote:
Chris Mair wrote:
Hello,
I'd like to start working on the following TODO item:
Referential Integrity / Support triggers on columns
Is somebody else already working on this?
No one, I think.
Isn't this the REFERENCING clause? I think there was a partial patch
submitted already for this.
The patch appears unrelated to column-level triggers:
http://momjian.postgresql.org/cgi-bin/pgpatches2
It is unrelated, but AFAIK Greg Mullane is working on this (actual column
based triggers) and has the intial workings of a patch already in
progress I'm CC'ing him so he can clarify but I'd hold off till you spoke
with him... and we should probably update the TODO once he speaks up as well.
--
Robert Treat
Build A Brighter Lamp :: Linux Apache {middleware} PostgreSQL
---(end of broadcast)---
TIP 8: explain analyze is your friend
Re: [HACKERS] REL8_0_STABLE and 8.0.1 release client logging difference
Oleg Bartunov wrote: Hi there, I noticed client error logging was changed in REL8_0_STABLE in compare with 8.0.1 release. 8.0.1: tycho=# select * from pg_stas where srelnae='tycho'; ERROR: relation pg_stas does not exist tycho=# \q REL8_0_STABLE: tycho=# select * from pg_stas where srelnae='tycho'; tycho=# \q ostgresql.conf was the same. Uh, you ran the query and got no error message from STABLE? That seems almost impossible for us to have broken. There must be some other reason. -- Bruce Momjian| http://candle.pha.pa.us pgman@candle.pha.pa.us | (610) 359-1001 + If your life is a hard drive, | 13 Roberts Road + Christ can be your backup.| Newtown Square, Pennsylvania 19073 ---(end of broadcast)--- TIP 9: the planner will ignore your desire to choose an index scan if your joining column's datatypes do not match
Re: [HACKERS] REL8_0_STABLE and 8.0.1 release client logging difference
On Sat, 12 Mar 2005, Bruce Momjian wrote: Oleg Bartunov wrote: Hi there, I noticed client error logging was changed in REL8_0_STABLE in compare with 8.0.1 release. 8.0.1: tycho=# select * from pg_stas where srelnae='tycho'; ERROR: relation pg_stas does not exist tycho=# \q REL8_0_STABLE: tycho=# select * from pg_stas where srelnae='tycho'; tycho=# \q ostgresql.conf was the same. Uh, you ran the query and got no error message from STABLE? That seems almost impossible for us to have broken. There must be some other reason. this is very annoying. Regards, Oleg _ Oleg Bartunov, sci.researcher, hostmaster of AstroNet, Sternberg Astronomical Institute, Moscow University (Russia) Internet: oleg@sai.msu.su, http://www.sai.msu.su/~megera/ phone: +007(095)939-16-83, +007(095)939-23-83 ---(end of broadcast)--- TIP 1: subscribe and unsubscribe commands go to [EMAIL PROTECTED]
Re: [HACKERS] REL8_0_STABLE and 8.0.1 release client logging difference
Oleg Bartunov wrote: On Sat, 12 Mar 2005, Bruce Momjian wrote: Oleg Bartunov wrote: Hi there, I noticed client error logging was changed in REL8_0_STABLE in compare with 8.0.1 release. 8.0.1: tycho=# select * from pg_stas where srelnae='tycho'; ERROR: relation pg_stas does not exist tycho=# \q REL8_0_STABLE: tycho=# select * from pg_stas where srelnae='tycho'; tycho=# \q ostgresql.conf was the same. Uh, you ran the query and got no error message from STABLE? That seems almost impossible for us to have broken. There must be some other reason. this is very annoying. Can you actually reproduce the failure by downloading different versions of CVS and trying it? I just tested with REL8_0_STABLE and get the error message just fine. -- Bruce Momjian| http://candle.pha.pa.us pgman@candle.pha.pa.us | (610) 359-1001 + If your life is a hard drive, | 13 Roberts Road + Christ can be your backup.| Newtown Square, Pennsylvania 19073 ---(end of broadcast)--- TIP 2: you can get off all lists at once with the unregister command (send unregister YourEmailAddressHere to [EMAIL PROTECTED])
Re: [HACKERS] REL8_0_STABLE and 8.0.1 release client logging difference
Oleg Bartunov oleg@sai.msu.su writes: REL8_0_STABLE: tycho=# select * from pg_stas where srelnae='tycho'; tycho=# \q Works fine for me in REL8_0_STABLE tip ... and it's working fine on all the build farm machines too, because this would surely cause all the regression tests to fail. Sure you didn't mistakenly change client_min_messages ? 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
[HACKERS] Strange postgres planner behaviour
Hi All, I want to descibe some strange behaviour of the postgres planner. I have 2 tables: wsdb=# \d q3c Table public.q3c Column | Type | Modifiers ++--- ipix | bigint | errbox | box| ra | real | dec| real | Indexes: ipix_idx btree (ipix) CLUSTER rtree_ind rtree (errbox) And the other table wsdb=# \d q3c_subset Table public.q3c_subset Column | Type | Modifiers ++--- ipix | bigint | errbox | box| ra | real | dec| real | When I run the following query, the plan for it is index scan, and it's ok. wsdb=# EXPLAIN SELECT * FROM q3c_subset AS uu,q3c WHERE (q3c.ipixuu.dec::bigint AND q3c.ipixuu.ra::bigint) AND (q3c.ipixuu.ra::bigint AND q3c.ipixuu.dec::bigint) ; QUERY PLAN - Nested Loop (cost=0.01..270564956.56 rows=4221207699 width=96) - Seq Scan on q3c_subset uu (cost=0.00..2314.72 rows=113972 width=48) - Index Scan using ipix_idx on q3c (cost=0.01..1262.80 rows=37038 width=48) Index Cond: ((q3c.ipix (outer.dec)::bigint) AND (q3c.ipix (outer.ra)::bigint) AND (q3c.ipix (outer.ra)::bigint) AND (q3c.ipix (outer.dec)::bigint)) (4 rows) But, when in my query I replace one AND to OR (see below), I have the sequential scan. BUT THIS IS NOT the reason why I wrote this letter, the main surprising thing is that even if I set enable_seq_scan to off the plan for new query is still seq. scan!!! So the planner don't even consider the index scan plan in that case (see below). wsdb=# EXPLAIN SELECT * FROM q3c_subset AS uu,q3c WHERE (q3c.ipixuu.dec::bigint AND q3c.ipixuu.ra::bigint) OR (q3c.ipixuu.ra::bigint AND q3c.ipixuu.dec::bigint) ; QUERY PLAN --- Nested Loop (cost=2428.69..13676776298.93 rows=71760530869 width=96) Join Filter: (((outer.ipix (inner.dec)::bigint) AND (outer.ipix (inner.ra)::bigint)) OR ((outer.ipix (inner.ra)::bigint) AND (outer.ipix (inner.dec)::bigint))) - Seq Scan on q3c (cost=0.00..60928.16 rows=316 width=48) - Materialize (cost=2428.69..3568.41 rows=113972 width=48) - Seq Scan on q3c_subset uu (cost=0.00..2314.72 rows=113972 width=48) (5 rows) wsdb=# set enable_seqscan TO off; SET wsdb=# EXPLAIN SELECT * FROM q3c_subset AS uu,q3c WHERE (q3c.ipixuu.dec::bigint AND q3c.ipixuu.ra::bigint) OR (q3c.ipixuu.ra::bigint AND q3c.ipixuu.dec::bigint) ; QUERY PLAN --- Nested Loop (cost=22428.69..13876776298.93 rows=71760530869 width=96) Join Filter: (((outer.ipix (inner.dec)::bigint) AND (outer.ipix (inner.ra)::bigint)) OR ((outer.ipix (inner.ra)::bigint) AND (outer.ipix (inner.dec)::bigint))) - Seq Scan on q3c (cost=1.00..100060928.16 rows=316 width=48) - Materialize (cost=12428.69..13568.41 rows=113972 width=48) - Seq Scan on q3c_subset uu (cost=1.00..12314.72 rows=113972 width=48) (5 rows) I tried this queries on 7.4.6 and 8.0.1 and the result is the same. So, Why the planner cannot use the index scan for that case ? What is wrong ? Thank you in advance. Sergey Sergey E. Koposov Sternberg Astronomical Institute, Moscow University (Russia) Max-Planck Institute for Astronomy (Germany) Internet: [EMAIL PROTECTED], http://lnfm1.sai.msu.su/~math/ ---(end of broadcast)--- TIP 7: don't forget to increase your free space map settings
Re: [HACKERS] Strange postgres planner behaviour
Sergey E. Koposov [EMAIL PROTECTED] writes: I want to descibe some strange behaviour of the postgres planner. It's not strange exactly: the mechanism for OR indexscan and the mechanism for nestloop join indexscan are separate and don't talk to each other. So you don't get to have a join inner indexscan that involves an OR condition. I have some vague ideas about replacing orindxpath.c entirely, once we have some infrastructure for doing OR indexscans via bitmap union. But it's not just around the corner. In the meantime you might try expressing your query as a UNION. regards, tom lane ---(end of broadcast)--- TIP 6: Have you searched our list archives? http://archives.postgresql.org
