Re: [PERFORM] Problem with 7.4.5 and webmin 1.8 in grant function

[EMAIL PROTECTED] wrote: I used you perl script and found the error => [EMAIL PROTECTED] tmp]# perl relacl.pl DBI connect('dbname=template1;port=5432','postgres',...) failed: FATAL: IDENT authentication failed for user "postgres" at relacl.pl line 21 Error in connect to DBI:Pg:dbname=template1;por

Re: [PERFORM] Problem with 7.4.5 and webmin 1.8 in grant function

> Ok - I must be looking at the *updated* FC3 distribution... > > I may have 'jumped the gun' a little - the situation I describe above > will prevent *any* access at all to Pg from webmin. If this is the case > then check you have (perl) DBI and (perl) DBD-Pg components installed. > > If on the ot

Re: [PERFORM] seq scan cache vs. index cache smackdown

Merlin Moncure wrote: readv and writev are in the single unix spec...and yes ... On some systems they might just be implemented as a loop inside the library, or even as a macro. You sure? Requirements like this: http://www.opengroup.org/onlinepubs/007908799/xsh/write.html "Write requests of {PIPE

Re: [PERFORM] Problem with 7.4.5 and webmin 1.8 in grant function

Mark Kirkwood wrote: If on the other hand you can do *some* Pg admin from webmin, and you are only having problems with the grants then there is something it does not like about the *particular* statement. The way to debug this is to do a tiny perl DBI program that tries to execute the statement :

Re: [PERFORM] Problem with 7.4.5 and webmin 1.8 in grant function

[EMAIL PROTECTED] wrote: I would suspect a DBI/DBD installation issue, either perl DBI cannot find DBD-Pg (not installed ?) or DBD-Pg cannot find your Pg 7.4.5. I note that FC3 comes with Pg 7.4.6 - did you installed 7.4.5 from source? If so this could be why the perl database modules cannot find i

Re: [PERFORM] bad performances using hashjoin

Quoting Tom Lane <[EMAIL PROTECTED]>: > Klint Gore <[EMAIL PROTECTED]> writes: > > Is having an order by in a view legal? > > Not according to the SQL spec, but PG has allowed it for several releases. > (The same goes for ORDER BY in a sub-select, which is actually pretty > much the same thing ..

Re: [PERFORM] seq scan cache vs. index cache smackdown

"Merlin Moncure" <[EMAIL PROTECTED]> writes: > Is there a reason why readv/writev have not been considered in the past? Lack of portability, and lack of obvious usefulness that would justify dealing with the lack of portability. I don't think there's any value in trying to write ordinary buffers

Re: [PERFORM] seq scan cache vs. index cache smackdown

> Magnus Hagander wrote: > > I don't think that's correct either. Scatter/Gather I/O is used to SQL > > Server can issue reads for several blocks from disks into it's own > > buffer cache with a single syscall even if these buffers are not > > sequential. It did make significant performance improve

Re: [PERFORM] bad performances using hashjoin

Gaetano Mendola wrote: I think is due the fact that first queries were performed in peakhours. A memory intensive operation takes 7.5 times longer during heavy loads. Doesn't this suggest that swapping of working memory is occurring? ---(end of broadcast)-

Re: [PERFORM] Effects of IDLE processes

Christopher Browne wrote: > After a long battle with technology, Gaetano Mendola <[EMAIL PROTECTED]>, an > earthling, wrote: > >>JM wrote: >> >>>Hi ALL, >>> >>> I was wondering if there is a DB performance reduction if >>>there are a lot of IDLE processes. >>> >>>30786 ?S 0:00 po

Re: [PERFORM] bad performances using hashjoin

Tom Lane wrote: > but this behavior isn't reproduced in the later message, so I wonder if > it wasn't an artifact of something else taking a chunk of time. I think is due the fact that first queries were performed in peakhours. Regards Gaetano Mendola ---(end of broad