Re: [HACKERS] Allow GRANT/REVOKE permissions to be applied to all
Josh Berkus wrote: And overall, I'd think it would make the feature a *lot* less useful; basically it would encourage a lot of DBAs to organize their schemas by security level, which is not really what schemas are for. This does seem conceptually cleaner than GRANT ON NEW TABLES, which to me has a flavor of action-at-a-distance about it. Does anyone see any cases where it's really important to have the distinction between acting on existing tables and acting on future tables? Databases which are already in production. I suggested it, of course, because I would utilize the distinction if it was available. I don't know about other users. Do we perhaps want a pg_find tool instead, rather than getting too clever inside the backend? pg_find --type=table --schema=foo --name='system_*' --execute='GRANT ALL ON % TO myuser' -- Richard Huxton Archonet Ltd ---(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] 7.2.7 - 8.0.1 Bundles Ready ...
Dave Page wrote: Urgh. No offence to Peter, but I think it's a helluva lot messier having all those symlinks. That wasn't my idea. -- Peter Eisentraut http://developer.postgresql.org/~petere/ ---(end of broadcast)--- TIP 5: Have you checked our extensive FAQ? http://www.postgresql.org/docs/faq
Re: [HACKERS] Our getopt_long() doesn't do abbreviations or NLS
Tom Lane wrote: I just noticed that our port/getopt_long.c substitute implementation does not accept abbreviated names for long options: That is known, but since we don't advertise that feature, it's not a problem. Barring objections, I'm going to modify our version to allow unique abbreviations too. Sure, if you like. Should it be gettext'ified? Probably. -- Peter Eisentraut http://developer.postgresql.org/~petere/ ---(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] Allow GRANT/REVOKE permissions to be applied to all
Richard Huxton wrote: Do we perhaps want a pg_find tool instead, rather than getting too clever inside the backend? pg_find --type=table --schema=foo --name='system_*' --execute='GRANT ALL ON % TO myuser' We really should reimplement our query language in Scheme and implement SQL on top of that. It will make many things much easier. :-) -- Peter Eisentraut http://developer.postgresql.org/~petere/ ---(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] 7.2.7 - 8.0.1 Bundles Ready ...
So do I get rid of the src directory altogether then, since apparently nobody likes, or wants, it? :) On Tue, 1 Feb 2005, Peter Eisentraut wrote: Dave Page wrote: Urgh. No offence to Peter, but I think it's a helluva lot messier having all those symlinks. That wasn't my idea. -- Peter Eisentraut http://developer.postgresql.org/~petere/ Marc G. Fournier Hub.Org Networking Services (http://www.hub.org) Email: [EMAIL PROTECTED] Yahoo!: yscrappy ICQ: 7615664 ---(end of broadcast)--- TIP 1: subscribe and unsubscribe commands go to [EMAIL PROTECTED]
Re: [HACKERS] Allow GRANT/REVOKE permissions to be applied to all
At 2005-02-01 11:02:52 +0100, [EMAIL PROTECTED] wrote: We really should reimplement our query language in Scheme and implement SQL on top of that. It will make many things much easier. :-) Speaking of which, see http://schematics.sourceforge.net -- ams ---(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] Allow GRANT/REVOKE permissions to be applied to all
At 2005-02-01 16:31:32 +0530, [EMAIL PROTECTED] wrote: Speaking of which, see http://schematics.sourceforge.net Actually, http://schematics.sourceforge.net/schemeql.html -- ams ---(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] Connect By for 8.0
I notice the CONNECT BY patch has been updated for 8.0: http://gppl.moonbone.ru/ Seriously, we really need to get this into 8.1. Convert it to the standard WITH RECURSIVE syntax if necessary... Chris ---(end of broadcast)--- TIP 6: Have you searched our list archives? http://archives.postgresql.org
[HACKERS] STABLE functions
Hello all, I saw that STABLE-defined functions
don't get replaced by their output, shoudn't they ?
Following shows that VOLATILE and STABLE functions outputs
won't get into the Filter, while IMMUTABLE will.
Documentation says that STABLE is the modifier to use for functions
which don't change output within a single query, isn't the shown one
a single query ?
Thanks in advance
--strk;
-- VOLATILE
update pg_proc set provolatile = 'v' where proname = 'find_srid';
UPDATE 1
explain analyze select * from input.geobit_5 where the_geom
setsrid('BOX3D(.7e+06 4.6e+06, .8e+06 4.83e+06)'::box3d,
find_srid('input','geobit_5','the_geom'));
QUERY PLAN
--
Seq Scan on geobit_5 (cost=0.00..1708.79 rows=1 width=379) (actual
time=586.979..1099.565 rows=255 loops=1)
Filter: (the_geom
setsrid('01030001000500C05C2541308C5141C05C2541CC6C5241006A2841CC6C5241006A2841308C5141C05C2541308C5141'::geometry,
find_srid('input'::character varying, 'geobit_5'::character varying,
'the_geom'::character varying)))
Total runtime: 1099.989 ms
(3 rows)
-- STABLE
update pg_proc set provolatile = 's' where proname = 'find_srid';
UPDATE 1
explain analyze select * from input.geobit_5 where the_geom
setsrid('BOX3D(.7e+06 4.6e+06, .8e+06 4.83e+06)'::box3d,
find_srid('input','geobit_5','the_geom'));
QUERY PLAN
--
Index Scan using geobit_5_gist on geobit_5 (cost=0.00..6.02 rows=1 width=379)
(actual time=2.084..42.157 rows=255 loops=1)
Index Cond: (the_geom
setsrid('01030001000500C05C2541308C5141C05C2541CC6C5241006A2841CC6C5241006A2841308C5141C05C2541308C5141'::geometry,
find_srid('input'::character varying, 'geobit_5'::character varying,
'the_geom'::character varying)))
Total runtime: 42.835 ms
(3 rows)
-- IMMUTABLE
update pg_proc set provolatile = 'i' where proname = 'find_srid';
UPDATE 1
explain analyze select * from input.geobit_5 where the_geom
setsrid('BOX3D(.7e+06 4.6e+06, .8e+06 4.83e+06)'::box3d,
find_srid('input','geobit_5','the_geom'));
QUERY PLAN
Index Scan using geobit_5_gist on geobit_5 (cost=0.00..1095.52 rows=298
width=379) (actual time=0.127..18.010 rows=255 loops=1)
Index Cond: (the_geom
'010320787F01000500C05C2541308C5141C05C2541CC6C5241006A2841CC6C5241006A2841308C5141C05C2541308C5141'::geometry)
Total runtime: 18.276 ms
(3 rows)
---(end of broadcast)---
TIP 7: don't forget to increase your free space map settings
Re: [HACKERS] 7.2.7 - 8.0.1 Bundles Ready ...
-Original Message- From: Marc G. Fournier [mailto:[EMAIL PROTECTED] Sent: 01 February 2005 10:52 To: Peter Eisentraut Cc: Dave Page; Marc G. Fournier; Tom Lane; pgsql-hackers@postgresql.org; David Fetter Subject: Re: [HACKERS] 7.2.7 - 8.0.1 Bundles Ready ... So do I get rid of the src directory altogether then, since apparently nobody likes, or wants, it? :) Fine with me. It'll reduce the number of webpages built on svr2 somewhat as well :-) Regards, Dave. ---(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] 7.2.7 - 8.0.1 Bundles Ready ...
Marc G. Fournier wrote: So do I get rid of the src directory altogether then, since apparently nobody likes, or wants, it? :) Sure. Just to recap, I believe my complaint at the time was that release announcements and the like were inconsistent regarding the version names (not anymore, I think). But having duplicate directories on the FTP server really doesn't help that. :) -- Peter Eisentraut http://developer.postgresql.org/~petere/ ---(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] 7.3.8 under FC3 takes excessive semaphores?
-Original Message- From: Tom Lane [mailto:[EMAIL PROTECTED] Sent: 31 January 2005 16:35 To: Mark Cave-Ayland Cc: pgsql-hackers@postgresql.org Subject: Re: [HACKERS] 7.3.8 under FC3 takes excessive semaphores? (cut) Judging by the symptoms, you have built a version with what we now call --disable-spinlocks; that is, it didn't figure out how to do assembly TAS on your platform and fell back to using SysV semaphores for spinlocks. Quite aside from the drain on semaphores, the performance is going to be spectacularly bad, so you'd better fix that. regards, tom lane Hi Tom, I'd just about managed to come to the same conclusion before your email arrived by spending the afternoon with gdb tracing into the LWLock code :) I've just installed 7.4.6 on the same box and this time the spinlocks are correctly picked up and everything works as expected. I think rather than fixing the 7.3.x source, we'll take the plunge and plan for a complete dump and restore of the database cluster over a weekend. Many thanks, Mark. WebBased Ltd South West Technology Centre Tamar Science Park Plymouth PL6 8BT T: +44 (0)1752 791021 F: +44 (0)1752 791023 W: http://www.webbased.co.uk ---(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] [NOVICE] Last ID Problem
On Tue, Feb 01, 2005 at 06:31:30PM +1100, John Hansen wrote: Since OID's are now deprecated, and will eventually disappear, wouldn't it be a good idea, to have INSERT and UPDATE return a copy of the tuple that was inserted/updated? How about the TID? -- Alvaro Herrera ([EMAIL PROTECTED]) El destino baraja y nosotros jugamos (A. Schopenhauer) ---(end of broadcast)--- TIP 4: Don't 'kill -9' the postmaster
Re: [HACKERS] [NOVICE] Last ID Problem
Since OID's are now deprecated, and will eventually disappear, wouldn't it be a good idea, to have INSERT and UPDATE return a copy of the tuple that was inserted/updated? How about the TID? Yea, that'd work. As long as you can get an arbitrary column back out, 'as it was at the time it was committed'. Since not everything runs in a transaction,. And someone might have modified the row by the time you get to fetching it back out Or in terms of tuples,. No longer exist, if vacuum full have run... ... JOhn ---(end of broadcast)--- TIP 7: don't forget to increase your free space map settings
[HACKERS] float4 regression test failed on linux parisc
I am getting a float4 regression test failure. I have extracted the SQL from both the float4 and float8 tests below. Both should return NAN I looked at the code, The float4div does the operation as float8's then checks the value. The value is a valid float8 NAN. The call to CheckFloat4Val is missing a cast back to float4. If I put the cast in I get the expected results (NAN). SELECT 'Infinity'::float4 / 'Infinity'::float4; psql:test.sql:1: ERROR: type real value out of range: overflow SELECT 'Infinity'::float8 / 'Infinity'::float8; ?column? -- NaN (1 row) ---(end of broadcast)--- TIP 1: subscribe and unsubscribe commands go to [EMAIL PROTECTED]
Re: [HACKERS] Group-count estimation statistics
On Mon, 31 Jan 2005 14:40:08 -0500, Tom Lane [EMAIL PROTECTED] wrote: Manfred Koizar [EMAIL PROTECTED] writes: That's not what I meant. I tried to say that if we have a GROUP BY several columns and one of these columns alone has more than N/10 distinct values, there's no way to get less than that many groups. Oh, I see, you want a max calculation in there too. Seems reasonable. Any objections? Yes. :-( What I said is only true in the absence of any WHERE clause (or join). Otherwise the same cross-column correlation issues you tried to work around with the N/10 clamping might come back through the backdoor. I'm not sure whether coding for such a narrow use case is worth the trouble. Forget my idea. Servus Manfred ---(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] 7.2.7 - 8.0.1 Bundles Ready ...
/pub/src is now gone ... On Tue, 1 Feb 2005, Dave Page wrote: -Original Message- From: Marc G. Fournier [mailto:[EMAIL PROTECTED] Sent: 01 February 2005 10:52 To: Peter Eisentraut Cc: Dave Page; Marc G. Fournier; Tom Lane; pgsql-hackers@postgresql.org; David Fetter Subject: Re: [HACKERS] 7.2.7 - 8.0.1 Bundles Ready ... So do I get rid of the src directory altogether then, since apparently nobody likes, or wants, it? :) Fine with me. It'll reduce the number of webpages built on svr2 somewhat as well :-) Regards, Dave. Marc G. Fournier Hub.Org Networking Services (http://www.hub.org) Email: [EMAIL PROTECTED] Yahoo!: yscrappy ICQ: 7615664 ---(end of broadcast)--- TIP 5: Have you checked our extensive FAQ? http://www.postgresql.org/docs/faq
Re: [HACKERS] Our getopt_long() doesn't do abbreviations or NLS
Peter Eisentraut [EMAIL PROTECTED] writes: Tom Lane wrote: Should it be gettext'ified? Probably. I seem to recall that there was some special consideration for files that would conditionally show up in multiple executables. Or were you going to fix that by having just one .mo file for all the clients? regards, tom lane ---(end of broadcast)--- TIP 2: you can get off all lists at once with the unregister command (send unregister YourEmailAddressHere to [EMAIL PROTECTED])
[HACKERS] Updated FAQ
I have udpated our main FAQ. I was shocked at out stale some of the information was. It wasn't technically wrong but needed a good cleaning. Let me know if anyone sees any other needed improvements. -- 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 8: explain analyze is your friend
Re: [HACKERS] [NOVICE] Last ID Problem
John Hansen [EMAIL PROTECTED] writes: Since OID's are now deprecated, and will eventually disappear, No one has stated that they will disappear. wouldn't it be a good idea, to have INSERT and UPDATE return a copy of the tuple that was inserted/updated? How about the TID? Yea, that'd work. You could only trust it for the duration of the inserting or updating transaction. Which might be enough ... but changing it would certainly break all existing apps that use this feature. I think the correct solution is not to mess with what's admittedly a legacy aspect of our client API. Instead we should invent the INSERT RETURNING and UPDATE RETURNING commands that have been discussed repeatedly (see the pghackers archives). That would allow people to get what they want, and do so in only one network round trip, without any artificial dependencies on OIDs or TIDs or anything else. It'd be unportable, but surely no more so than relying on OIDs or TIDs ... 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: [HACKERS] Group-count estimation statistics
Manfred Koizar [EMAIL PROTECTED] writes: On Mon, 31 Jan 2005 14:40:08 -0500, Tom Lane [EMAIL PROTECTED] wrote: Oh, I see, you want a max calculation in there too. Seems reasonable. Any objections? Yes. :-( What I said is only true in the absence of any WHERE clause (or join). Otherwise the same cross-column correlation issues you tried to work around with the N/10 clamping might come back through the backdoor. I'm not sure whether coding for such a narrow use case is worth the trouble. Forget my idea. No, I think it's still good. The WHERE clauses are factored in separately (essentially by assuming their selectivity on the grouped rows is the same as it would be on the raw rows, which is pretty bogus but it's hard to do better). The important point is that the group count before WHERE filtering certainly does behave as you suggest, and so the clamp is going to be overoptimistic if it clamps to less than the largest individual number-of-distinct-values. regards, tom lane ---(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] Allow GRANT/REVOKE permissions to be applied to all schema
Richard, pg_find --type=table --schema=foo --name='system_*' --execute='GRANT ALL ON % TO myuser' Hey, that's a way keen idea. Regardless of what we do with GRANT/REVOKE. You don't happen to, uh, have any code for that? -- Josh Berkus Aglio Database Solutions San Francisco ---(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] Allow GRANT/REVOKE permissions to be applied to all
Josh Berkus wrote: Richard, pg_find --type=table --schema=foo --name='system_*' --execute='GRANT ALL ON % TO myuser' Hey, that's a way keen idea. Regardless of what we do with GRANT/REVOKE. You don't happen to, uh, have any code for that? Well, currently, what you see posted above is the full extent of the idea. If there's a feeling it'd be useful I could pull my finger out and have a working prototype ready in Perl fairly quickly. It'd take me a while to get something decent in C though. -- Richard Huxton Archonet Ltd ---(end of broadcast)--- TIP 4: Don't 'kill -9' the postmaster
Re: [HACKERS] Allow GRANT/REVOKE permissions to be applied to all schema
Josh Berkus wrote:
pg_find --type=table --schema=foo --name='system_*'
--execute='GRANT ALL ON % TO myuser'
Hey, that's a way keen idea. Regardless of what we do with
GRANT/REVOKE. You don't happen to, uh, have any code for that?
psql -t -A -c select tablename from pg_tables where schemaname = 'foo'
and tablename like 'system_%'; | xargs -i -n 1 psql -c 'grant all on
{} to myuser;'
--
Peter Eisentraut
http://developer.postgresql.org/~petere/
---(end of broadcast)---
TIP 6: Have you searched our list archives?
http://archives.postgresql.org
Re: [HACKERS] [NOVICE] Last ID Problem
I have a suggestion... For libpq: Since OID's are now deprecated, and will eventually disappear, wouldn't it be a good idea, to have INSERT and UPDATE return a copy of the tuple that was inserted/updated? This way, you could have a funtion to fetch an arbitrary named column from that tuple. Like: last_insert_value(tuple,'column_name') With a default to return the primary key? Sincerely, Joshua D. Drake ... John ---(end of broadcast)--- TIP 1: subscribe and unsubscribe commands go to [EMAIL PROTECTED] -- Command Prompt, Inc., home of Mammoth PostgreSQL - S/ODBC and S/JDBC Postgresql support, programming shared hosting and dedicated hosting. +1-503-667-4564 - [EMAIL PROTECTED] - http://www.commandprompt.com PostgreSQL Replicator -- production quality replication for PostgreSQL begin:vcard fn:Joshua Drake n:Drake;Joshua org:Command Prompt, Inc. adr:;;PO Box 215 ;Cascade Locks;OR;97014;US email;internet:[EMAIL PROTECTED] title:Consultant tel;work:503-667-4564 tel;fax:503-210-0334 x-mozilla-html:FALSE url:http://www.commandprompt.com version:2.1 end:vcard ---(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] STABLE functions
strk [EMAIL PROTECTED] writes: Hello all, I saw that STABLE-defined functions don't get replaced by their output, shoudn't they ? Following shows that VOLATILE and STABLE functions outputs won't get into the Filter, while IMMUTABLE will. The examples are acting exactly as they should. See http://www.postgresql.org/docs/8.0/static/xfunc-volatility.html regards, tom lane ---(end of broadcast)--- TIP 6: Have you searched our list archives? http://archives.postgresql.org
Re: [HACKERS] Patent issues and 8.1
A new organization called the Software Freedom Law Center was announced yesterday; that seems like it may be one of the best places open-source groups could go for questions like this ARC pending patent. Eben Moglen (The FSF's main lawyer and Columbia Law prof), Diane Peters (OSDL's general counsel), and Lawrence Lesseg (Stanford law prof behind Creative Commons) are behind this organization; so it seems to have pretty good credentials. http://news.com.com/2100-7344_3-5557962.html The center said in a statement that it will employ two full-time intellectual property attorneys, who will help provide consulting services to nonprofit open-source organizations. The staff count is expected to expand to four later in 2005. The help they provide could include training lawyers, supporting litigation, dealing with licensing problems and keeping managing contributions to open-source projects, the center said. ---(end of broadcast)--- TIP 5: Have you checked our extensive FAQ? http://www.postgresql.org/docs/faq
Re: [HACKERS] float4 regression test failed on linux parisc
Jim Buttafuoco [EMAIL PROTECTED] writes: I am getting a float4 regression test failure. I have extracted the SQL from both the float4 and float8 tests below. Both should return NAN I looked at the code, The float4div does the operation as float8's then checks the value. The value is a valid float8 NAN. The call to CheckFloat4Val is missing a cast back to float4. If I put the cast in I get the expected results (NAN). This report is about as clear as mud :-(. What platform is this, and what source code change are you proposing *exactly* ? regards, tom lane ---(end of broadcast)--- TIP 1: subscribe and unsubscribe commands go to [EMAIL PROTECTED]
Re: [HACKERS] Allow GRANT/REVOKE permissions to be applied to all schema
Josh Berkus josh@agliodbs.com writes: The problem with this approach is it leaves us with no way to REVOKE permissions on a specific table from a user who has permissions on the SCHEMA. Our permissions model is completely additive, so if you did: Why is that a problem? The complaint seems about analogous to saying we should not have groups because you can't REVOKE rights from an individual user if he has them via a group membership. And overall, I'd think it would make the feature a *lot* less useful; basically it would encourage a lot of DBAs to organize their schemas by security level, which is not really what schemas are for. Why would this mechanism encourage that more than the other one would? regards, tom lane ---(end of broadcast)--- TIP 8: explain analyze is your friend
Re: [HACKERS] float4 regression test failed on linux parisc
Tom Lane wrote: Jim Buttafuoco [EMAIL PROTECTED] writes: I am getting a float4 regression test failure. I have extracted the SQL from both the float4 and float8 tests below. Both should return NAN I looked at the code, The float4div does the operation as float8's then checks the value. The value is a valid float8 NAN. The call to CheckFloat4Val is missing a cast back to float4. If I put the cast in I get the expected results (NAN). This report is about as clear as mud :-(. What platform is this, and I believe the parisc platform is the HP 9000 series. Probably running Debian. http://parisc-linux.org Sincerely, Joshua D. Drake what source code change are you proposing *exactly* ? regards, tom lane ---(end of broadcast)--- TIP 1: subscribe and unsubscribe commands go to [EMAIL PROTECTED] -- Command Prompt, Inc., your source for PostgreSQL replication, professional support, programming, managed services, shared and dedicated hosting. Home of the Open Source Projects plPHP, plPerlNG, pgManage, and pgPHPtoolkit. Contact us now at: +1-503-667-4564 - http://www.commandprompt.com begin:vcard fn:Joshua D. Drake n:Drake;Joshua D. org:Command Prompt, Inc. adr:;;PO Box 215;Cascade Locks;Oregon;97014;USA email;internet:[EMAIL PROTECTED] title:Consultant tel;work:503-667-4564 tel;fax:503-210-0334 note:Command Prompt, Inc. is the largest and oldest US based commercial PostgreSQL support provider. We provide the only commercially viable integrated PostgreSQL replication solution, but also custom programming, and support. We authored the book Practical PostgreSQL, the procedural language plPHP, and adding trigger capability to plPerl. x-mozilla-html:FALSE url:http://www.commandprompt.com/ version:2.1 end:vcard ---(end of broadcast)--- TIP 4: Don't 'kill -9' the postmaster
Re: [HACKERS] Allow GRANT/REVOKE permissions to be applied to all schema
Josh Berkus josh@agliodbs.com writes: And overall, I'd think it would make the feature a *lot* less useful; basically it would encourage a lot of DBAs to organize their schemas by security level, which is not really what schemas are for. that's not the way Oracle do things? one schema per user and the objects of the user in its own schema? at least i was tought that way. regards, Jaime Casanova _ Do You Yahoo!? Información de Estados Unidos y América Latina, en Yahoo! Noticias. Visítanos en http://noticias.espanol.yahoo.com ---(end of broadcast)--- TIP 4: Don't 'kill -9' the postmaster
Re: [HACKERS] Huge memory consumption during vacuum (v.8.0)
On Sun, 30 Jan 2005, Oleg Bartunov wrote: Seems, postmaster eats expected amount of memory now ! Will see how long it will proceeded. Probably, my case should be documented somewhere. just to inform - vacuum took almost 48 hours ! Another possibility is to use CLUSTER or a rewriting ALTER TABLE to shrink the space, but be aware that this requires a transient second copy of the table and indexes. I aware, but I don't so much free space :) I run wsdb=# create table c_usno as select * from usno order by ipix; to cluster table and notice that disk usage changing in discontinuous manner. After some reduction I see no changes. postmaster is doing something PID USER PR NI VIRT RES SHR S %CPU %MEMTIME+ COMMAND 12723 postgres 18 0 207m 196m 204m D 21.6 19.4 52:17.12 postmaster I see that pgsql_tmp/ contains files, looks like clustered table. What postmaster is doing if disk usage doesn't changed ? Is there TODO for scaling VACUUM FULL ? regards, tom lane 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 5: Have you checked our extensive FAQ? http://www.postgresql.org/docs/faq 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 9: the planner will ignore your desire to choose an index scan if your joining column's datatypes do not match 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 9: the planner will ignore your desire to choose an index scan if your joining column's datatypes do not match
Re: [HACKERS] FunctionCallN improvement.
a_ogawa [EMAIL PROTECTED] writes:
I made the test program to measure the effect of this macro.
Well, if we're going to be tense about this, let's actually be tense
about it. Your test program isn't a great model for what's going to
happen in fmgr.c, because you've designed it so that Nargs cannot be
known at compile time. In the fmgr routines, Nargs is certainly a
compile-time constant, and so implementations that can exploit that
will have an advantage.
Also, we can take advantage of some improvements in the MemSet macro
family that occurred since fmgr.c was last rewritten. I see no reason
not to use MemSetLoop directly, since the fcinfo struct will have the
correct size and correct alignment.
In addition to your original macro, I tried two other variants: one
that uses MemSetLoop with a loop length rounded to the next higher
multiple of 4, and one that expects the argisnull settings to be written
out directly, in the same style as is currently done in FunctionCall1
and FunctionCall2. (This amounts to unrolling the loop in the original
macro; something that could be done by the compiler given a constant
Nargs, but it seems not to be done by the compilers I tested.)
I tested two cases: NARGS = 2, which is certainly the single most
critical case, and NARGS = 5, which is probably the largest number
of arguments that we really care too much about. (You have to hand-edit
the test program and recompile to adjust NARGS, since the point is to
treat it as a compile-time constant.)
Here are wall-clock timings on the architectures and compilers I have at
hand:
NARGS = 2
MemSetLoop OrigMacro SetMacroUnrolled
i386, gcc -O2 37.655s 6.411s 7.060s 6.362s
i386, gcc -O6 35.420s 1.129s 1.814s 0.567s
PPC, gcc -O254.033s 6.754s 11.138s 6.438s
HPPA, gcc -O2 58.82s 10.38s 9.79s 7.85s
HPPA, cc +O260.39s 13.43s 8.40s 7.31s
NARGS = 5
MemSetLoop OrigMacro SetMacroUnrolled
i386, gcc -O2 37.566s 11.329s 7.688s 8.874s
i386, gcc -O6 32.992s 5.928s 2.881s 0.566s
PPC, gcc -O286.300s 19.048s 14.626s 8.751s
HPPA, gcc -O2 58.28s 15.09s 13.42s 14.37s
HPPA, cc +O258.23s 8.96s 12.88s 7.28s
(I used different loop counts on the different machines to get similar
overall times for the memset case; so it's OK to compare numbers across
a row but not down a column.)
Based on this I think we ought to go with the unrolled approach, ie,
we'll create a macro to initialize the fixed fields of fcinfo but fill
in the arg and argisnull arrays with code like what's already in
FunctionCall2:
fcinfo.arg[0] = arg1;
fcinfo.arg[1] = arg2;
fcinfo.argnull[0] = false;
fcinfo.argnull[1] = false;
If anyone would like to try the results on other platforms, my test
program is attached.
regards, tom lane
#include postgres.h
#include fmgr.h
#define NARGS 2 /* Unrolled code can handle up
to 10 */
/*
* Initialize minimum fields of FunctionCallInfoData that must be
* initialized.
*/
#define InitFunctionCallInfoData(Fcinfo, Flinfo, Nargs) \
do { \
int i_; \
(Fcinfo)-flinfo = Flinfo; \
(Fcinfo)-context = NULL;\
(Fcinfo)-resultinfo = NULL; \
(Fcinfo)-isnull = false;\
(Fcinfo)-nargs = Nargs; \
for(i_ = 0; i_ Nargs; i_++) (Fcinfo)-argnull[i_] = false; \
} while(0)
/*
* dummyFunc is to control excessive optimization.
* When this function is not called from loop, the initialization of
* FunctionCallInfoData might move outside of the loop by gcc.
*/
void dummyFunc(FunctionCallInfoData *fcinfo, int cnt)
{
fcinfo-arg[0] = Int32GetDatum(cnt);
}
void TestMemSet(int cnt)
{
FunctionCallInfoData fcinfo;
printf(test MemSetLoop(%d): %d\n, NARGS, cnt);
for(; cnt; cnt--) {
MemSetLoop(fcinfo, 0, sizeof(fcinfo));
dummyFunc(fcinfo, cnt);
}
}
void TestOrigMacro(int cnt)
{
FunctionCallInfoData fcinfo;
printf(test OrigMacro(%d): %d\n, NARGS, cnt);
for(; cnt; cnt--) {
InitFunctionCallInfoData(fcinfo, NULL, NARGS);
dummyFunc(fcinfo, cnt);
}
}
#undef InitFunctionCallInfoData
#define InitFunctionCallInfoData(Fcinfo, Flinfo, Nargs) \
do { \
(Fcinfo)-flinfo = Flinfo; \
Re: [HACKERS] Huge memory consumption during vacuum (v.8.0)
Oleg Bartunov oleg@sai.msu.su writes: I see that pgsql_tmp/ contains files, looks like clustered table. What postmaster is doing if disk usage doesn't changed ? Most likely doing a disk-based merge sort ... regards, tom lane ---(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] Huge memory consumption during vacuum (v.8.0)
On Tue, 1 Feb 2005, Tom Lane wrote: Oleg Bartunov oleg@sai.msu.su writes: I see that pgsql_tmp/ contains files, looks like clustered table. What postmaster is doing if disk usage doesn't changed ? Most likely doing a disk-based merge sort ... just interesting - multiway, in-place or just place merge sort ? regards, tom lane 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] float4 regression test failed on linux parisc
Source: CSV HEAD (As of yesterday)
Platform: HP PARISC (HP 710)
OS: Debian Sarge
File: src/backend/utils/adt/float.c
Change:
CheckFloat4Val(result);
To:
CheckFloat4Val((float4)result);
I tested this on my parisc box and it passed all tests. This could just be an
issue with a very old CPU/floating
point unit.
I can send a patch in, but since this seems to work on other platforms, I
thought I would ask here first.
Sorry about the cryptic message, it was before my first cup of java.
Jim
Datum
float4div(PG_FUNCTION_ARGS)
{
float4 arg1 = PG_GETARG_FLOAT4(0);
float4 arg2 = PG_GETARG_FLOAT4(1);
double result;
if (arg2 == 0.0)
ereport(ERROR,
(errcode(ERRCODE_DIVISION_BY_ZERO),
errmsg(division by zero)));
/* Do division in float8, then check for overflow */
result = (float8) arg1 / (float8) arg2;
CheckFloat4Val(result);
PG_RETURN_FLOAT4((float4) result);
}
-- Original Message ---
From: Tom Lane [EMAIL PROTECTED]
To: Jim Buttafuoco [EMAIL PROTECTED]
Cc: pgsql-hackers pgsql-hackers@postgresql.org
Sent: Tue, 01 Feb 2005 12:06:30 -0500
Subject: Re: [HACKERS] float4 regression test failed on linux parisc
Jim Buttafuoco [EMAIL PROTECTED] writes:
I am getting a float4 regression test failure. I have extracted the SQL
from both the float4 and float8 tests
below.
Both should return NAN
I looked at the code, The float4div does the operation as float8's then
checks the value. The value is a valid
float8 NAN. The call to CheckFloat4Val is missing a cast back to float4.
If I put the cast in I get the expected
results (NAN).
This report is about as clear as mud :-(. What platform is this, and
what source code change are you proposing *exactly* ?
regards, tom lane
---(end of broadcast)---
TIP 1: subscribe and unsubscribe commands go to [EMAIL PROTECTED]
--- End of Original Message ---
---(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] float4 regression test failed on linux parisc
Jim Buttafuoco [EMAIL PROTECTED] writes: I am trying to get this system working for the buildfarm as there are NO other HP PARISC system on the farm. I still use a PA-RISC machine as my primary development environment, so I can assure you that platform gets tested every day. I'm not particularly interested in catering to a broken compiler by removing the ability to detect float4 overflow, which is what the result would be if we use your patch. In short: if you want this to work, I think you should file a bug with Debian, not here. regards, tom lane ---(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] float4 regression test failed on linux parisc
Jim Buttafuoco [EMAIL PROTECTED] writes: Change: CheckFloat4Val(result); To: CheckFloat4Val((float4)result); CheckFloat4Val is defined to take a double, so whatever the above is accomplishing is wrong: probably it's masking an out-of-range result. I think you've hit a bug in Debian's version of gcc for PA-RISC. regards, tom lane ---(end of broadcast)--- TIP 6: Have you searched our list archives? http://archives.postgresql.org
Re: [HACKERS] float4 regression test failed on linux parisc
Tom, The issue is with a select 'Infinity'::float4/'Infinity'::float4; which should return NAN. without the cast I get the overflow message from CheckFloat4Val with the cast I get NAN (as expected). How about testing for isnan() inside CheckFloat4Val (just for PARISC / Linux)? I am trying to get this system working for the buildfarm as there are NO other HP PARISC system on the farm. Jim -- Original Message --- From: Tom Lane [EMAIL PROTECTED] To: [EMAIL PROTECTED] Cc: pgsql-hackers pgsql-hackers@postgresql.org Sent: Tue, 01 Feb 2005 17:13:52 -0500 Subject: Re: [HACKERS] float4 regression test failed on linux parisc Jim Buttafuoco [EMAIL PROTECTED] writes: Change: CheckFloat4Val(result); To: CheckFloat4Val((float4)result); CheckFloat4Val is defined to take a double, so whatever the above is accomplishing is wrong: probably it's masking an out-of-range result. I think you've hit a bug in Debian's version of gcc for PA-RISC. regards, tom lane --- End of Original Message --- ---(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] FunctionCallN improvement.
On February 1, 2005 01:23 pm, Tom Lane wrote: a_ogawa [EMAIL PROTECTED] writes: I made the test program to measure the effect of this macro. Well, if we're going to be tense about this, let's actually be tense about it. Your test program isn't a great model for what's going to happen in fmgr.c, because you've designed it so that Nargs cannot be known at compile time. In the fmgr routines, Nargs is certainly a compile-time constant, and so implementations that can exploit that will have an advantage. Also, we can take advantage of some improvements in the MemSet macro family that occurred since fmgr.c was last rewritten. I see no reason not to use MemSetLoop directly, since the fcinfo struct will have the correct size and correct alignment. In addition to your original macro, I tried two other variants: one that uses MemSetLoop with a loop length rounded to the next higher multiple of 4, and one that expects the argisnull settings to be written out directly, in the same style as is currently done in FunctionCall1 and FunctionCall2. (This amounts to unrolling the loop in the original macro; something that could be done by the compiler given a constant Nargs, but it seems not to be done by the compilers I tested.) I tested two cases: NARGS = 2, which is certainly the single most critical case, and NARGS = 5, which is probably the largest number of arguments that we really care too much about. (You have to hand-edit the test program and recompile to adjust NARGS, since the point is to treat it as a compile-time constant.) Here are wall-clock timings on the architectures and compilers I have at hand: NARGS = 2 MemSetLoop OrigMacro SetMacroUnrolled i386, gcc -O2 37.655s 6.411s 7.060s 6.362s i386, gcc -O6 35.420s 1.129s 1.814s 0.567s PPC, gcc -O2 54.033s 6.754s 11.138s 6.438s HPPA, gcc -O2 58.82s 10.38s 9.79s 7.85s HPPA, cc +O2 60.39s 13.43s 8.40s 7.31s NARGS = 5 MemSetLoop OrigMacro SetMacroUnrolled i386, gcc -O2 37.566s 11.329s 7.688s 8.874s i386, gcc -O6 32.992s 5.928s 2.881s 0.566s PPC, gcc -O2 86.300s 19.048s 14.626s 8.751s HPPA, gcc -O2 58.28s 15.09s 13.42s 14.37s HPPA, cc +O2 58.23s 8.96s 12.88s 7.28s I see simular comparitive times on an UltraSparc running Solaris. (I used different loop counts on the different machines to get similar overall times for the memset case; so it's OK to compare numbers across a row but not down a column.) Based on this I think we ought to go with the unrolled approach, ie, we'll create a macro to initialize the fixed fields of fcinfo but fill in the arg and argisnull arrays with code like what's already in FunctionCall2: fcinfo.arg[0] = arg1; fcinfo.arg[1] = arg2; fcinfo.argnull[0] = false; fcinfo.argnull[1] = false; If anyone would like to try the results on other platforms, my test program is attached. regards, tom lane -- Darcy Buskermolen Wavefire Technologies Corp. ph: 250.717.0200 fx: 250.763.1759 http://www.wavefire.com ---(end of broadcast)--- TIP 1: subscribe and unsubscribe commands go to [EMAIL PROTECTED]
Re: [HACKERS] [NOVICE] Last ID Problem
On Tue, 2005-02-01 at 11:24 -0300, Alvaro Herrera wrote: How about the TID? That wouldn't be sufficiently stable for use by client applications, I believe: a concurrent VACUUM FULL could mean your TID no longer points at what you think it does. -Neil ---(end of broadcast)--- TIP 6: Have you searched our list archives? http://archives.postgresql.org
Re: [HACKERS] [NOVICE] Last ID Problem
Neil Conway [EMAIL PROTECTED] writes: On Tue, 2005-02-01 at 11:24 -0300, Alvaro Herrera wrote: How about the TID? That wouldn't be sufficiently stable for use by client applications, I believe: a concurrent VACUUM FULL could mean your TID no longer points at what you think it does. It'd be safe enough within the same transaction, since VACUUM can't kill a tuple inserted by an open transaction; nor could VACUUM FULL touch the table at all, since you'll be holding at least a writer's lock on the table. But this is all moot since INSERT/UPDATE RETURNING is really the way to go, on grounds of functionality, speed, and not breaking backward compatibility for existing client code. regards, tom lane ---(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] [NOVICE] Last ID Problem
On Tue, 2005-02-01 at 17:50 -0500, Tom Lane wrote: It'd be safe enough within the same transaction, since VACUUM can't kill a tuple inserted by an open transaction; nor could VACUUM FULL touch the table at all, since you'll be holding at least a writer's lock on the table. True, but it still seems rather fragile -- it would be quite easy for people to get this wrong and not realize it (and then wonder why their application is silently corrupting data at odd times). Also, it might constrain out ability to improve how we garbage collect expired tuples in the future, although that's less of a concern. But this is all moot since INSERT/UPDATE RETURNING is really the way to go, on grounds of functionality, speed, and not breaking backward compatibility for existing client code. Agreed. Also, I believe we could do this without needing a protocol version bump. -Neil ---(end of broadcast)--- TIP 8: explain analyze is your friend
Re: [HACKERS] FunctionCallN improvement.
On Tue, 01 Feb 2005 16:23:56 -0500, Tom Lane [EMAIL PROTECTED] wrote: a_ogawa [EMAIL PROTECTED] writes: I made the test program to measure the effect of this macro. Well, if we're going to be tense about this, let's actually be tense about it. Your test program isn't a great model for what's going to happen in fmgr.c, because you've designed it so that Nargs cannot be known at compile time. In the fmgr routines, Nargs is certainly a compile-time constant, and so implementations that can exploit that will have an advantage. big snip Here are some numbers for AMD64 (gcc -O2 -I /opt/include/postgresql/server/ pg_test.c -o pg_test): [EMAIL PROTECTED] miker $ time ./pg_test -memset 10 test MemSetLoop(2): 10 real1m15.896s user1m15.881s sys 0m0.006s [EMAIL PROTECTED] miker $ time ./pg_test -origmacro 10 test OrigMacro(2): 10 real0m4.217s user0m4.215s sys 0m0.001s [EMAIL PROTECTED] miker $ time ./pg_test -setmacro 10 test SetMacro(2): 10 real0m4.217s user0m4.216s sys 0m0.001s [EMAIL PROTECTED] miker $ time ./pg_test -unrolled 10 test Unrolled(2): 10 real0m4.218s user0m4.215s sys 0m0.002s and now with -O6: [EMAIL PROTECTED] miker $ time ./pg_test -memset 10 test MemSetLoop(2): 10 real1m13.624s user1m13.542s sys 0m0.001s [EMAIL PROTECTED] miker $ time ./pg_test -origmacro 10 test OrigMacro(2): 10 real0m2.929s user0m2.926s sys 0m0.001s [EMAIL PROTECTED] miker $ time ./pg_test -setmacro 10 test SetMacro(2): 10 real0m2.929s user0m2.926s sys 0m0.000s [EMAIL PROTECTED] miker $ time ./pg_test -unrolled 10 test Unrolled(2): 10 real0m2.510s user0m2.508s sys 0m0.001s Now with NARGS = 5, -O2: [EMAIL PROTECTED] miker $ time ./pg_test -memset 10 test MemSetLoop(5): 10 real1m15.204s user1m15.175s sys 0m0.002s [EMAIL PROTECTED] miker $ time ./pg_test -origmacro 10 test OrigMacro(5): 10 real0m10.027s user0m10.022s sys 0m0.001s [EMAIL PROTECTED] miker $ time ./pg_test -setmacro 10 test SetMacro(5): 10 real0m4.177s user0m4.177s sys 0m0.000s [EMAIL PROTECTED] miker $ time ./pg_test -unrolled 10 test Unrolled(5): 10 real0m5.013s user0m5.011s sys 0m0.000s And once more, with -O6: [EMAIL PROTECTED] miker $ time ./pg_test -memset 10 test MemSetLoop(5): 10 real1m47.090s user1m46.972s sys 0m0.000s [EMAIL PROTECTED] miker $ time ./pg_test -origmacro 10 test OrigMacro(5): 10 real0m8.367s user0m8.358s sys 0m0.000s [EMAIL PROTECTED] miker $ time ./pg_test -setmacro 10 test SetMacro(5): 10 real0m3.349s user0m3.345s sys 0m0.000s [EMAIL PROTECTED] miker $ time ./pg_test -unrolled 10 test Unrolled(5): 10 real0m3.347s user0m3.343s sys 0m0.000s Hope the numbers help! -- Mike Rylander [EMAIL PROTECTED] GPLS -- PINES Development Database Developer http://open-ils.org ---(end of broadcast)--- TIP 6: Have you searched our list archives? http://archives.postgresql.org
Re: [HACKERS] [NOVICE] Last ID Problem
No one has stated that they will disappear. Ohh,... just the impression I've been getting when speaking with people. ... John ---(end of broadcast)--- TIP 1: subscribe and unsubscribe commands go to [EMAIL PROTECTED]
Re: [HACKERS] [NOVICE] Last ID Problem
With a default to return the primary key? Of course, that would be ideal ... :) ---(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] FunctionCallN improvement.
Sorry, forgot the compiler version. gcc (GCC) 3.3.4 20040623 (Gentoo Linux 3.3.4-r1, ssp-3.3.2-2, pie-8.7.6) On Wed, 2 Feb 2005 01:12:04 +, Mike Rylander [EMAIL PROTECTED] wrote: On Tue, 01 Feb 2005 16:23:56 -0500, Tom Lane [EMAIL PROTECTED] wrote: a_ogawa [EMAIL PROTECTED] writes: I made the test program to measure the effect of this macro. Well, if we're going to be tense about this, let's actually be tense about it. Your test program isn't a great model for what's going to happen in fmgr.c, because you've designed it so that Nargs cannot be known at compile time. In the fmgr routines, Nargs is certainly a compile-time constant, and so implementations that can exploit that will have an advantage. big snip Here are some numbers for AMD64 (gcc -O2 -I /opt/include/postgresql/server/ pg_test.c -o pg_test): [EMAIL PROTECTED] miker $ time ./pg_test -memset 10 test MemSetLoop(2): 10 real1m15.896s user1m15.881s sys 0m0.006s [EMAIL PROTECTED] miker $ time ./pg_test -origmacro 10 test OrigMacro(2): 10 real0m4.217s user0m4.215s sys 0m0.001s [EMAIL PROTECTED] miker $ time ./pg_test -setmacro 10 test SetMacro(2): 10 real0m4.217s user0m4.216s sys 0m0.001s [EMAIL PROTECTED] miker $ time ./pg_test -unrolled 10 test Unrolled(2): 10 real0m4.218s user0m4.215s sys 0m0.002s and now with -O6: [EMAIL PROTECTED] miker $ time ./pg_test -memset 10 test MemSetLoop(2): 10 real1m13.624s user1m13.542s sys 0m0.001s [EMAIL PROTECTED] miker $ time ./pg_test -origmacro 10 test OrigMacro(2): 10 real0m2.929s user0m2.926s sys 0m0.001s [EMAIL PROTECTED] miker $ time ./pg_test -setmacro 10 test SetMacro(2): 10 real0m2.929s user0m2.926s sys 0m0.000s [EMAIL PROTECTED] miker $ time ./pg_test -unrolled 10 test Unrolled(2): 10 real0m2.510s user0m2.508s sys 0m0.001s Now with NARGS = 5, -O2: [EMAIL PROTECTED] miker $ time ./pg_test -memset 10 test MemSetLoop(5): 10 real1m15.204s user1m15.175s sys 0m0.002s [EMAIL PROTECTED] miker $ time ./pg_test -origmacro 10 test OrigMacro(5): 10 real0m10.027s user0m10.022s sys 0m0.001s [EMAIL PROTECTED] miker $ time ./pg_test -setmacro 10 test SetMacro(5): 10 real0m4.177s user0m4.177s sys 0m0.000s [EMAIL PROTECTED] miker $ time ./pg_test -unrolled 10 test Unrolled(5): 10 real0m5.013s user0m5.011s sys 0m0.000s And once more, with -O6: [EMAIL PROTECTED] miker $ time ./pg_test -memset 10 test MemSetLoop(5): 10 real1m47.090s user1m46.972s sys 0m0.000s [EMAIL PROTECTED] miker $ time ./pg_test -origmacro 10 test OrigMacro(5): 10 real0m8.367s user0m8.358s sys 0m0.000s [EMAIL PROTECTED] miker $ time ./pg_test -setmacro 10 test SetMacro(5): 10 real0m3.349s user0m3.345s sys 0m0.000s [EMAIL PROTECTED] miker $ time ./pg_test -unrolled 10 test Unrolled(5): 10 real0m3.347s user0m3.343s sys 0m0.000s Hope the numbers help! -- Mike Rylander [EMAIL PROTECTED] GPLS -- PINES Development Database Developer http://open-ils.org -- Mike Rylander [EMAIL PROTECTED] GPLS -- PINES Development Database Developer http://open-ils.org ---(end of broadcast)--- TIP 1: subscribe and unsubscribe commands go to [EMAIL PROTECTED]
Re: [HACKERS] Huge memory consumption during vacuum (v.8.0)
On Tue, 1 Feb 2005, Tom Lane wrote: Oleg Bartunov oleg@sai.msu.su writes: I see that pgsql_tmp/ contains files, looks like clustered table. What postmaster is doing if disk usage doesn't changed ? Most likely doing a disk-based merge sort ... so, it uses 'work_mem' as a buffer ? regards, tom lane ---(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 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 5: Have you checked our extensive FAQ? http://www.postgresql.org/docs/faq
