Re: [HACKERS] Improving count(*)
Tom Lane wrote: Simon Riggs [EMAIL PROTECTED] writes: From here, another proposal. We have a GUC called count_uses_estimate that is set to off by default. If set to true, then a count(*) will use the planner logic to estimate number of rows in the table and return that as the answer, rather than actually count the row. Ugh. Why not just provide a function to retrieve the planner estimate, but *not* call it count(*)? It would fit nicely with the contrib/dbsize stuff (or I should say, the stuff formerly in dbsize...) That would completely remove my needs for a fast count() - all I want is a way to quickly estimate table sizes for an operator's display. Tom's suggestion would provide exactly that. -- Steve Wampler -- [EMAIL PROTECTED] The gods that smiled on your birth are now laughing out loud. ---(end of broadcast)--- TIP 2: Don't 'kill -9' the postmaster
[HACKERS] Minor (very) feature request...
Would it be (is it?) possible to add timestamp to the log messages put out by postgresql? I've got several databases running in an environment where users have this annoying habit of coming up to me with (Oh yes, three days ago around 4pm our instrument had trouble writing to database X.). Having some way of telling which messages were output when would be helpful in such cases, since I'm not allowed to beat the users into submission... Thanks! -- Steve Wampler -- [EMAIL PROTECTED] The gods that smiled on your birth are now laughing out loud. ---(end of broadcast)--- TIP 4: Don't 'kill -9' the postmaster
Re: [HACKERS] Minor (very) feature request...
On Thu, 2003-12-04 at 09:52, Andrew Dunstan wrote: Marc G. Fournier wrote: run it through syslog? or set log_timestamp = true in postgresql.conf ? Thanks - for some reason I was assuming that only applied to logging connections. Should have tried it... Thanks again! -- Steve Wampler -- [EMAIL PROTECTED] The gods that smiled on your birth are now laughing out loud. ---(end of broadcast)--- TIP 5: Have you checked our extensive FAQ? http://www.postgresql.org/docs/faqs/FAQ.html
Re: [HACKERS] PostgreSQL and SOAP, suggestions?
Out of curiousity, what is the purpose of putting the qry:ROWSET description into the message at all (header or not)? Isn't it a perfectly valid SOAP message (and just as parseable) with that removed? I freely admit to not being a soap expert, but similar SOAP messages I generate from queries seem to work fine without this metadata. Is having it required by some part of the SOAP spec I don't understand? Thanks! On Tue, 2003-04-01 at 05:29, mlw wrote: That was part of the same bug as above, it now outputs this: ?xml version = 1.0? mwssql:Envelope xmlns:mwssql=http://www.mohawksoft.com/mwssql/envelope; mwssql:Header exec:sqlupdate cgrpairs set ratio=0 where srcitem=100098670/exec:sql exec:affected2657/exec:affected qry:sqlselect * from ztitles limit 2/qry:sql qry:ROWSET qry:ROW columns=28 t:acdundefined/t:acd t:muzenbrundefined/t:muzenbr t:cat2undefined/t:cat2 t:cat3undefined/t:cat3 t:cat4undefined/t:cat4 t:performerundefined/t:performer t:performer2undefined/t:performer2 t:titleundefined/t:title t:artist1undefined/t:artist1 t:engineerundefined/t:engineer t:producerundefined/t:producer t:labelnameundefined/t:labelname t:catalogundefined/t:catalog t:distributundefined/t:distribut t:releasedundefined/t:released t:origrelundefined/t:origrel t:nbrdiscsundefined/t:nbrdiscs t:sparundefined/t:spar t:minutesundefined/t:minutes t:secondsundefined/t:seconds t:monostereoundefined/t:monostereo t:studioliveundefined/t:studiolive t:availableundefined/t:available t:previewsundefined/t:previews t:pnotesundefined/t:pnotes t:artistidundefined/t:artistid t:datasrcundefined/t:datasrc t:extidundefined/t:extid /qry:ROW /qry:ROWSET /mwssql:Header mwssql:Body ROWSET columns=28 rows=2 ROW ROWID=0 acdP/acd muzenbr68291/muzenbr cat2Performer/cat2 cat3Jazz Instrument/cat3 cat4Guitar/cat4 performerSteve Khan/performer performer2Khan, Steve/performer2 titleEvidence/title artist1/artist1 engineer/engineer producer/producer labelnameNovus/labelname catalog3074/catalog distributBMG/distribut released02/13/1990/released origreln/a/origrel nbrdiscs1/nbrdiscs sparn/a/spar minutes/minutes seconds/seconds monostereoStereo/monostereo studioliveStudio/studiolive availableN/available previews/previews pnotes/pnotes artistid100025343/artistid datasrc1/datasrc extid68291/extid /ROW ROW ROWID=1 acdP/acd muzenbr67655/muzenbr cat2Collection/cat2 cat3Jazz Instrument/cat3 cat4/cat4 performerVarious Artists/performer performer2Various Artists/performer2 titleMetropolitan Opera House Jam Session/title artist1/artist1 engineer/engineer producer/producer labelnameJazz Anthology/labelname catalog550212/catalog distributn/a/distribut released1992/released origreln/a/origrel nbrdiscs1/nbrdiscs sparn/a/spar minutes/minutes seconds/seconds monostereoMono/monostereo studioliveLive/studiolive availableN/available previews/previews pnotes/pnotes artistid100050450/artistid datasrc1/datasrc extid67655/extid /ROW /ROWSET /mwssql:Body /mwssql:Envelope -- Steve Wampler [EMAIL PROTECTED] National Solar Observatory ---(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] PostgreSQL and SOAP, version 7.4/8.0
On Fri, 2003-03-28 at 14:39, mlw wrote: I was thinking of using SOAP over HTTP as the protocol, and a minimalist version at best. If the people want more let them add it. I have an HTTP service class in my open source library. It would br trivial to accept a SQL query formatted as a GET request, and then execute the query and, using libpq, format the result as XML. It should be simple enough to do. It would be easy. I've done something similar (using ODBC to get to PostgreSQL) - but using a language none of the rest of you are likely to be interested in (Unicon). Works just fine, though the implementation (deliberately, by personal preference) avoids accepting arbitrary SQL statements from SOAP clients, instead forcing the clients to use an RPC interface so I can do sanity checking in the Unicon [which I know better than I know PostgreSQL...] SOAP servers. I, too, opted for a 'minimal-SOAP' implementation. A 'real' implementation boggles the mind. -- Steve Wampler [EMAIL PROTECTED] National Solar Observatory ---(end of broadcast)--- TIP 4: Don't 'kill -9' the postmaster
Re: [HACKERS] Threads
On Sat, 4 Jan 2003, Christopher Kings-Lynne wrote: Also remember that in even well developed OS's like FreeBSD, all a process's threads will execute only on one CPU. I doubt that - it certainly isn't the case on Linux and Solaris. A thread may *start* execution on the same CPU as it's parent, but native threads are not likely to be constrained to a specific CPU with an SMP OS. -- Steve Wampler [EMAIL PROTECTED] National Solar Observatory ---(end of broadcast)--- TIP 5: Have you checked our extensive FAQ? http://www.postgresql.org/users-lounge/docs/faq.html
Re: [HACKERS] How much work is a native Windows application?
Christopher Browne wrote: If fixing PostgreSQL to work on Win32 caused a whole lot of breakage on the Unix side, that would _not_ be a win. It might do well on Win32, but breakage could lead to a LOSS of interest on Unix, as people decided to take the point of view that the developers considered it more important to toady to Win-Needs than to improve how it works on Unix. As a PostgreSQL user, I *wholeheartedly* agree. I have no need nor interest in a Win32 solution. Period. If I perceive that an effort to add a Win32 postgresql is adversely impacting the ongoing development of Unix-based PostgreSQL then I will start looking at other solutions. In fact, if you folks could find additional resources that would support Win32 development, it still seems to me that perhaps those resources could be better spent improving the Unix version. -- Steve Wampler -- [EMAIL PROTECTED] O sibile, si ergo. Fortibus es enaro. Nobile, demis trux. Demis phulla causan dux. ---(end of broadcast)--- TIP 6: Have you searched our list archives? http://archives.postgresql.org
