Re: [HACKERS] estimated_count() implementation
On Oct 21 05:09, Michael Fuhr wrote: I hadn't noticed the TODO item but about a year ago I posted a cursor_plan_rows() function and asked for comments. Ah! I didn't see this. The only reply was from Tom, who said, Given how far off it frequently is, I can't believe that any of the people who ask for the feature would find this a satisfactory answer :-( AFAIU, cursor_plan_rows() has some serious limitations like requiring to be executed for a portal. I was planning to make estimated_count() work for nodeAgg and custom calls too - as count() does. But OTOH, Tom's complaints look like still applicable for my estimated_count() too. Does this TODO need a little bit more clarification or we can count is a redundant one? Regards. ---(end of broadcast)--- TIP 1: 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] [PATCHES] Updates for vcbuild
[ various fixes ] I'm confused: which of the files in src/tools/msvc need to have Windows-style newlines, if any? GNU patch wants to strip the newlines from your patches, so it'd be easiest from here if the answer is none. Hmm. I think the answer should be none, yes. Both .bat and .pl/.pm can deal with unix style line breaks. Looking around, I think my own cvs is getting confused over the mix, and that's why it looks weird in the patch. //Magnus ---(end of broadcast)--- TIP 6: explain analyze is your friend
Re: [HACKERS] xlogdump fixups and WAL log question.
On Sat, 2006-10-21 at 19:24 -0400, Tom Lane wrote: Simon Riggs [EMAIL PROTECTED] writes: But they can be re-created anew with the same name each time? Or I guess not, but you redefine a view every 30 minutes to point to the latest one? If so, then I have a patch that will speed up COPY when in the same transaction as the table that created it. I've finally fixed a bug in my earlier prototypes that seems to make that work now, in all cases. Can you make the patch cover the case of begin; truncate foo; copy foo from ... commit; It might be infeasible to detect this case, but if it's not ... I think it is possible to detect this case without making catalog entries, so I'll give this a try. Methinks that the truncate *must* be the immediately preceding command, otherwise we might have a trigger executing to put rows back into the table before we COPY. I should also be able to get that to work with Insert Select without much bother too. We might also add this capability to COPY itself by providing a WITH TRUNCATE option, which would be even cleaner code-wise. We can add that to pg_dump so it will work with/without --single-transaction mode. That will change the permissions reqd slightly, but seems OK. I'll go for all of the above changes unless there are objections. -- Simon Riggs EnterpriseDB http://www.enterprisedb.com ---(end of broadcast)--- TIP 4: Have you searched our list archives? http://archives.postgresql.org
Re: [HACKERS] [PATCHES] smartvacuum() instead of autovacuum
Hitoshi Harada wrote: I am trying to implement smartvacuum(), which do vacuum only tables having many dead rows, instead of autovacuum. How is this different from what autovacuum does? -- Peter Eisentraut http://developer.postgresql.org/~petere/ ---(end of broadcast)--- TIP 3: Have you checked our extensive FAQ? http://www.postgresql.org/docs/faq
Re: [HACKERS] New CRC algorithm: Slicing by 8
Hi all, Michael Kounavis has given a green signal (please refer the forwarded message).Best regards,-- [EMAIL PROTECTED][EMAIL PROTECTED] gmail | hotmail | yahoo }.com -- Forwarded message --From: Kounavis, Michael E [EMAIL PROTECTED] Date: Oct 20, 2006 10:43 PMSubject: RE: CRC algorithm, Slicing By 8; concerns about patents infringementsTo: Gurjeet Singh [EMAIL PROTECTED], Michael Kounavis [EMAIL PROTECTED] Hi, Thank you for your interest on Slicing-by-8. No. Intel decided not to file a patent on this algorithm but to make it freely available under BSD license. You should have no problem using it. MIke From: Gurjeet Singh [mailto:[EMAIL PROTECTED]] Sent: Friday, October 20, 2006 5:50 AM To: Michael Kounavis Subject: CRC algorithm, Slicing By 8; concerns about patents infringements Hi Michael, Please refer the following post, and the conversation that followed: http://archives.postgresql.org/pgsql-hackers/2006-10/msg01015.php As is evident form that post, I have used the source code provided by you on sf.net, and modified it to suit PostgreSQL. Now the community is concerned if we will be infringing any patents. We all understand that that you (on behalf of Intel) have released the algorithm, and the code, under BSD license, which allows anybody to use it commercially, but we need assurance that we will not be infringing any patents owned by Intel by including your algorithm in PostgreSQL, because PostgreSQL is used/sold by many companies for profit. Best regards, -- [EMAIL PROTECTED] [EMAIL PROTECTED] gmail | hotmail | yahoo }.com
Re: [HACKERS] New CRC algorithm: Slicing by 8
On 10/22/06, Gregory Maxwell [EMAIL PROTECTED] wrote: On Opteron 265 his test code shows SB8 (the intel alg) is 2.48x fasterfor checksum and 1.95x faster for verify for the 800 * 1024 blocks of1 KB each workload. For 10 blocks of 8k I got simmlar results aswell. I think you meant800*1024 blocks of 1 MB each workload.-- [EMAIL PROTECTED][EMAIL PROTECTED] gmail | hotmail | yahoo }.com
Re: [HACKERS] estimated_count() implementation
On Sun, 2006-10-22 at 12:07 +0300, Volkan YAZICI wrote: On Oct 21 05:09, Michael Fuhr wrote: I hadn't noticed the TODO item but about a year ago I posted a cursor_plan_rows() function and asked for comments. Ah! I didn't see this. The only reply was from Tom, who said, Given how far off it frequently is, I can't believe that any of the people who ask for the feature would find this a satisfactory answer :-( AFAIU, cursor_plan_rows() has some serious limitations like requiring to be executed for a portal. I was planning to make estimated_count() work for nodeAgg and custom calls too - as count() does. But OTOH, Tom's complaints look like still applicable for my estimated_count() too. Does this TODO need a little bit more clarification or we can count is a redundant one? http://archives.postgresql.org/pgsql-hackers/2005-11/msg00943.php Is the source of the TODO item, though please read the upthread messages as to how we got there... I think it would be a useful function... -- Simon Riggs EnterpriseDB http://www.enterprisedb.com ---(end of broadcast)--- TIP 4: Have you searched our list archives? http://archives.postgresql.org
Re: [HACKERS] New CRC algorithm: Slicing by 8
On Sun, Oct 22, 2006 at 08:10:56PM +0530, Gurjeet Singh wrote: Hi all, Michael Kounavis has given a green signal (please refer the forwarded message). I don't think that helps. The publishing date of this article was March 2006. If this is really the first time this algorithm was published, that means that anyone else (or even the author) has the option of patenting this algorithm sometime before March 2007 and still claiming they invented it first. And realistically we would wait at least a year or three after that, because you don't get to see patents as they're applied for. Maybe March 2010 we can look into it... Have a nice day, -- Martijn van Oosterhout kleptog@svana.org http://svana.org/kleptog/ From each according to his ability. To each according to his ability to litigate. signature.asc Description: Digital signature
Re: [HACKERS] adminpack and pg_catalog
On Sat, 2006-10-21 at 12:37 +0200, Peter Eisentraut wrote: Dave Page wrote: If you change it you will make it useless as pgAdmin won't necessarily find the functions it expects. You might as well just remove it (which will almost certainly cause delays to pgAdmin - and pgInstallers - release as I'll need to find time to put it all back how it was). If pgAdmin is going to dictate what we do with adminpack, adminpack should rather be shipped with pgAdmin. Admin tools are critical. adminpack is being made available for any and all admin packages, so all tools, including for example psql *could* be enhanced to use those. Whether they do is up to them, but at least their life is potentially easier. -- Simon Riggs EnterpriseDB http://www.enterprisedb.com ---(end of broadcast)--- TIP 9: In versions below 8.0, the planner will ignore your desire to choose an index scan if your joining column's datatypes do not match
Re: [HACKERS] xlogdump fixups and WAL log question.
Simon Riggs wrote: On Sat, 2006-10-21 at 19:24 -0400, Tom Lane wrote: Can you make the patch cover the case of begin; truncate foo; copy foo from ... commit; It might be infeasible to detect this case, but if it's not ... I think it is possible to detect this case without making catalog entries, so I'll give this a try. Methinks that the truncate *must* be the immediately preceding command, otherwise we might have a trigger executing to put rows back into the table before we COPY. Hmm, is it possible to save the is empty info somewhere in local memory, perhaps the relcache (not necessarily propagated), and have heap_insert turn it off? That would help when you do things like begin; truncate foo, bar; copy foo from ... copy bar from ... commit; On the other hand, what happens if you do begin; truncate foo; -- another session copy foo from ... -- original session copy foo from ... commit; How do you detect that the table is no longer empty? -- Alvaro Herrerahttp://www.CommandPrompt.com/ PostgreSQL Replication, Consulting, Custom Development, 24x7 support ---(end of broadcast)--- TIP 9: In versions below 8.0, the planner will ignore your desire to choose an index scan if your joining column's datatypes do not match
Re: [HACKERS] xlogdump fixups and WAL log question.
Alvaro Herrera [EMAIL PROTECTED] writes: Simon Riggs wrote: I think it is possible to detect this case without making catalog entries, so I'll give this a try. Methinks that the truncate *must* be the immediately preceding command, otherwise we might have a trigger executing to put rows back into the table before we COPY. Hmm, is it possible to save the is empty info somewhere in local memory, perhaps the relcache (not necessarily propagated), and have heap_insert turn it off? The relcache isn't a very safe place to store state --- it's a cache, not stable storage. However, I don't understand why Simon is on about empty. ISTM the important state is new relfilenode assigned in this transaction. regards, tom lane ---(end of broadcast)--- TIP 3: Have you checked our extensive FAQ? http://www.postgresql.org/docs/faq
Re: [HACKERS] estimated_count() implementation
Simon Riggs [EMAIL PROTECTED] writes:
On Sun, 2006-10-22 at 12:07 +0300, Volkan YAZICI wrote:
But OTOH, Tom's complaints look like still applicable for my
estimated_count() too. Does this TODO need a little bit more
clarification or we can count is a redundant one?
http://archives.postgresql.org/pgsql-hackers/2005-11/msg00943.php
Is the source of the TODO item, though please read the upthread messages
as to how we got there...
I think there is a use-case for something like
select estimated_count('select * from ... where ...');
i.e. there are applications where a possibly-bad estimate is enough.
What I'm concerned about is the level of complaints from newbies who'll
expect it to be dead accurate all the time ...
BTW, you can build estimated_count() today in a few lines of plpgsql:
create or replace function estimated_count(text) returns float8 as $$
declare r text;
begin
for r in execute 'explain ' || $1 loop
return substring(r from 'rows=([0-9]+) ');
end loop;
end$$ language plpgsql strict;
I don't see that it really justifies any more work than that.
regards, tom lane
---(end of broadcast)---
TIP 6: explain analyze is your friend
Re: [HACKERS] New CRC algorithm: Slicing by 8
On 10/22/06, Martijn van Oosterhout kleptog@svana.org wrote: On Sun, Oct 22, 2006 at 08:10:56PM +0530, Gurjeet Singh wrote: Hi all, Michael Kounavis has given a green signal (please refer the forwarded message). I don't think that helps. The publishing date of this article was March 2006. If this is really the first time this algorithm was published, that means that anyone else (or even the author) has the option of patenting this algorithm sometime before March 2007 and still claiming they invented it first. And realistically we would wait at least a year or three after that, because you don't get to see patents as they're applied for. Maybe March 2010 we can look into it... Consudering the author has OK-d it and given how easy is to replace the algorithm, I don't see the reason for such carefulness? -- marko ---(end of broadcast)--- TIP 9: In versions below 8.0, the planner will ignore your desire to choose an index scan if your joining column's datatypes do not match
Re: [HACKERS] New CRC algorithm: Slicing by 8
Gurjeet Singh [EMAIL PROTECTED] writes: If possible, people should test it on different platforms, so as to ensure that it doesn't perform any worse than older implementation on any supported platform (please post the results, if you do test it). I didn't particularly trust the timing calculations in your benchmark program, so I made up my own low-tech test version (attached). I get the following timings for 1 million iterations of INIT_CRC32/COMP_CRC32/FIN_CRC32 on different buffer sizes, using gcc -O2 on some machines laying about the house: Std CRC Slice8 CRC HPPA (HPUX 10.20) 8192 bytes 44.897212 35.191499 1024 bytes 5.6390814.669850 64 bytes0.3774160.613195 PPC (Mac G4, Darwin 10.4.8) 8192 bytes 12.663135 12.158293 1024 bytes 1.5799401.614967 64 bytes0.1043100.229401 Intel Xeon EM64T (Fedora Core 5) 8192 bytes 4.4208797.633120 1024 bytes 0.5717940.819372 64 bytes0.0473540.071906 Intel Pentium 4 (Fedora Core 5) 8192 bytes 6.94232428.848572 (yes, really) 1024 bytes 0.9052593.625360 64 bytes0.0680650.260224 It's worth pointing out that this test program is biased in favor of the slice8 code about as far as it could possibly be: after the first iteration, the remaining 99 will find the cache as hot as possible. Furthermore, the test doesn't exercise misaligned or odd-length cases, which would incur extra start/stop overhead for slice8. These numbers are um, not impressive. Considering that a large fraction of our WAL records are pretty short, the fact that slice8 consistently loses at short buffer lengths is especially discouraging. Much of that ground could be made up perhaps with tenser coding of the initialization and finalization code, but it'd still not be worth taking any legal risk for AFAICS. regards, tom lane binnuzUvuPEGN.bin Description: my-crctest.tar.gz ---(end of broadcast)--- TIP 4: Have you searched our list archives? http://archives.postgresql.org
Re: [HACKERS] xlogdump fixups and WAL log question.
On Sun, 2006-10-22 at 12:12 -0400, Tom Lane wrote: Alvaro Herrera [EMAIL PROTECTED] writes: Simon Riggs wrote: I think it is possible to detect this case without making catalog entries, so I'll give this a try. Methinks that the truncate *must* be the immediately preceding command, otherwise we might have a trigger executing to put rows back into the table before we COPY. Hmm, is it possible to save the is empty info somewhere in local memory, perhaps the relcache (not necessarily propagated), and have heap_insert turn it off? The relcache isn't a very safe place to store state --- it's a cache, not stable storage. I was imagining adding this onto the Relation struct, just as we do with rd_createSubid and rd_targblock. That isn't a safe place to store that state so we can't do this across multiple backends. We wouldn't want that anyway since otherwise various statements would need to access shared state before they can act, which is not good. However, I don't understand why Simon is on about empty. ISTM the important state is new relfilenode assigned in this transaction. Thank you for supplying clarity of thought; empty would be important if we were taking full table locks, which we don't want to do (Christmas Past...). So we need not have the DML immediately following a truncate, only that a truncate has previously occurred within the top level transaction or an unaborted subtransaction. -- Simon Riggs EnterpriseDB http://www.enterprisedb.com ---(end of broadcast)--- TIP 6: explain analyze is your friend
[HACKERS] Crosstab question
Dear list,
I recently discovered the crosstab function in postgresql.
What Im trying to accomplish is turn this:
Suppliernumber Productnumber Price
0 2 0.8
0 3 1.2
1 2 0.9
1 3 1.1
Into this:
Productnumber Supplier1 Supplier2
2 0.8 0.9
3 1.2 1.1
The problem is that the data is being shifted when there is
no
price for Supplier1 for product 3:
Productnumber Supplier1 Supplier2
2 0.8 0.9
3 1.1(WRONG!)
Im using this command to retrieve the data:
select * from crosstab('select int_artnr, int_crednr,
flt_inkoopprijs from artcredinkoopprijzen where
int_crednr = 2 OR int_crednr = 3') as c(int_artnr integer, supp1
float4, supp2
float4);
Am I doing something wrong or is this a limitation of the
function?
With kind regards,
Paul
Re: [HACKERS] [PATCHES] pg_buffercache tidyup
Mark Kirkwood [EMAIL PROTECTED] writes: This is probably terrible timing, but I noticed Tom had done some nice tidying up on pg_freespacemap to eliminate the clumsy conversion to and from strings. This patch does a similar thing for pg_buffercache. Applied --- it is very late in the cycle, but minor code cleanup of this sort seems pretty safe. I did wonder about not showing buffers that are invalid or not in use (currently displays all attributes bar the id as NULL). Comments? I think we should leave it as-is. You can easily filter the null rows if you don't want 'em, while they might be handy for certain sorts of analysis. Besides, this module has already been out for one release so we shouldn't change its API on a whim. regards, tom lane ---(end of broadcast)--- TIP 4: Have you searched our list archives? http://archives.postgresql.org
Re: [HACKERS] [PATCHES] Updates for vcbuild
Magnus Hagander [EMAIL PROTECTED] writes: Hmm. I think the answer should be none, yes. Both .bat and .pl/.pm can deal with unix style line breaks. OK, patch applied and all ^M's removed in src/tools/msvc/ regards, tom lane ---(end of broadcast)--- TIP 1: 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] [PATCHES] smartvacuum() instead of autovacuum
Hi, Peter, How is this different from what autovacuum does? My application needs to do vacuum by itself, while autovacuum does it as daemon. The database is updated so frequently that normal vacuum costs too much and tables to be updated are not so many as the whole database is vacuumed. I want to use autovacuum except the feature of daemon, but want to control when to vacuum and which table to vacuum. So, nothing is different between autovacuum and smartvacuum(), but former is daemon and later is user function. c.f. I ran autovacuum before, and my batch script did vacuum while autovacuum did one as well on the other session at the same time. I found the vacuum analyze conflicts each other sometime... so I want to control vacuum my self. http://archives.postgresql.org/pgsql-bugs/2002-12/msg00198.php http://archives.postgresql.org/pgsql-general/2004-05/msg00015.php Regards, Hitoshi Harada -Original Message- From: Peter Eisentraut [mailto:[EMAIL PROTECTED] Sent: Sunday, October 22, 2006 10:08 PM To: Hitoshi Harada Cc: pgsql-hackers@postgresql.org Subject: Re: [PATCHES] smartvacuum() instead of autovacuum Hitoshi Harada wrote: I am trying to implement smartvacuum(), which do vacuum only tables having many dead rows, instead of autovacuum. How is this different from what autovacuum does? -- Peter Eisentraut http://developer.postgresql.org/~petere/ ---(end of broadcast)--- TIP 3: Have you checked our extensive FAQ? http://www.postgresql.org/docs/faq
Re: [HACKERS] New CRC algorithm: Slicing by 8
Tom Lane wrote: Bruce Momjian [EMAIL PROTECTED] writes: However, I am not sure getting a clarification from the author even helps us legally. Also, why are we more critical of an Intel-provided idea than any other idea we get from the community? Bitter experience with other companies. The problem is we have lots of companies involved, and I bet some we don't even know about (e.g. yahoo/gmail addresses), and with contributors who don't know that their employment agreement says anything they do while employed is company property. And we have Unisys involved now too. How worrying is that? :-( So unless we hear about a problem, I think we should use the code. It hasn't even been tested. One thing I'd want to know about is the performance effect on non-Intel machines. Sure. -- Bruce Momjian [EMAIL PROTECTED] EnterpriseDBhttp://www.enterprisedb.com + If your life is a hard drive, Christ can be your backup. + ---(end of broadcast)--- TIP 3: Have you checked our extensive FAQ? http://www.postgresql.org/docs/faq
Re: [HACKERS] [PATCHES] smartvacuum() instead of autovacuum
Hitoshi Harada [EMAIL PROTECTED] writes: How is this different from what autovacuum does? My application needs to do vacuum by itself, while autovacuum does it as daemon. The database is updated so frequently that normal vacuum costs too much and tables to be updated are not so many as the whole database is vacuumed. I want to use autovacuum except the feature of daemon, but want to control when to vacuum and which table to vacuum. So, nothing is different between autovacuum and smartvacuum(), but former is daemon and later is user function. This seems completely unconvincing. What are you going to do that couldn't be done by autovacuum? regards, tom lane ---(end of broadcast)--- TIP 5: don't forget to increase your free space map settings
Re: [HACKERS] New CRC algorithm: Slicing by 8
Bruce Momjian [EMAIL PROTECTED] writes: Tom Lane wrote: Bruce Momjian [EMAIL PROTECTED] writes: Also, why are we more critical of an Intel-provided idea than any other idea we get from the community? Bitter experience with other companies. The problem is we have lots of companies involved, and I bet some we don't even know about (e.g. yahoo/gmail addresses), It's not so much that I don't trust Intel as that a CRC algorithm is exactly the sort of nice little self-contained thing that people love to try to patent these days. What I am really afraid of is that someone else has already invented this same method (or something close enough to it) and filed for a patent that Intel doesn't know about either. I'd be wondering about that no matter where the code had come from. Given the numbers I posted earlier today, the proposal is dead in the water anyway, quite aside from any legal considerations. regards, tom lane ---(end of broadcast)--- TIP 3: Have you checked our extensive FAQ? http://www.postgresql.org/docs/faq
Re: [HACKERS] New CRC algorithm: Slicing by 8
Tom Lane wrote: Bruce Momjian [EMAIL PROTECTED] writes: Tom Lane wrote: Bruce Momjian [EMAIL PROTECTED] writes: Also, why are we more critical of an Intel-provided idea than any other idea we get from the community? Bitter experience with other companies. The problem is we have lots of companies involved, and I bet some we don't even know about (e.g. yahoo/gmail addresses), It's not so much that I don't trust Intel as that a CRC algorithm is exactly the sort of nice little self-contained thing that people love to try to patent these days. What I am really afraid of is that someone else has already invented this same method (or something close enough to it) and filed for a patent that Intel doesn't know about either. I'd be wondering about that no matter where the code had come from. Given the numbers I posted earlier today, the proposal is dead in the water anyway, quite aside from any legal considerations. Agreed. I just wanted to point out we have other sharks in the water. :-( -- Bruce Momjian [EMAIL PROTECTED] EnterpriseDBhttp://www.enterprisedb.com + If your life is a hard drive, Christ can be your backup. + ---(end of broadcast)--- TIP 2: Don't 'kill -9' the postmaster
Re: [HACKERS] [PATCHES] smartvacuum() instead of autovacuum
Ok, But my point is, autovacuum may corrupt with vacuum analyze command on another session. My intention of smartvacuum() is based on this. Any solution for this?? Regards, Hitoshi Harada -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Tom Lane Sent: Monday, October 23, 2006 11:10 AM To: Hitoshi Harada Cc: 'Peter Eisentraut'; pgsql-hackers@postgresql.org Subject: Re: [HACKERS] [PATCHES] smartvacuum() instead of autovacuum Hitoshi Harada [EMAIL PROTECTED] writes: How is this different from what autovacuum does? My application needs to do vacuum by itself, while autovacuum does it as daemon. The database is updated so frequently that normal vacuum costs too much and tables to be updated are not so many as the whole database is vacuumed. I want to use autovacuum except the feature of daemon, but want to control when to vacuum and which table to vacuum. So, nothing is different between autovacuum and smartvacuum(), but former is daemon and later is user function. This seems completely unconvincing. What are you going to do that couldn't be done by autovacuum? regards, tom lane ---(end of broadcast)--- TIP 5: don't forget to increase your free space map settings ---(end of broadcast)--- TIP 5: don't forget to increase your free space map settings
Re: [HACKERS] New CRC algorithm: Slicing by 8
On Sun, Oct 22, 2006 at 06:06:13PM -0400, Tom Lane wrote: Intel Xeon EM64T (Fedora Core 5) 8192 bytes4.4208797.633120 1024 bytes0.5717940.819372 64 bytes 0.0473540.071906 Intel Pentium 4 (Fedora Core 5) 8192 bytes6.94232428.848572 (yes, really) 1024 bytes0.9052593.625360 64 bytes 0.0680650.260224 AMDX2 3800+ (Fedora Core 5) STD CRC SLICE8 CRC 8192 bytes8.5766357.170038 1024 bytes1.5043611.402446 64 bytes 0.1544590.144209 Odd that the AMD shows opposite of the two Intel numbers above, and that it was an Intel engineer who wrote it. My first speculation is that you did your Intel numbers backwards. My second speculation is that you already thought of that and confirmed before posting. :-) So yeah - not too impressive... Cheers, mark -- [EMAIL PROTECTED] / [EMAIL PROTECTED] / [EMAIL PROTECTED] __ . . _ ._ . . .__. . ._. .__ . . . .__ | Neighbourhood Coder |\/| |_| |_| |/|_ |\/| | |_ | |/ |_ | | | | | | \ | \ |__ . | | .|. |__ |__ | \ |__ | Ottawa, Ontario, Canada One ring to rule them all, one ring to find them, one ring to bring them all and in the darkness bind them... http://mark.mielke.cc/ ---(end of broadcast)--- TIP 9: In versions below 8.0, the planner will ignore your desire to choose an index scan if your joining column's datatypes do not match
Re: [HACKERS] New CRC algorithm: Slicing by 8
[EMAIL PROTECTED] writes: ... My first speculation is that you did your Intel numbers backwards. My second speculation is that you already thought of that and confirmed before posting. :-) Yah, I checked. Several times... but if anyone else wants to repeat the experiment, please do. Or look for bugs in either my test case or Gurjeet's. regards, tom lane ---(end of broadcast)--- TIP 5: don't forget to increase your free space map settings
Re: [HACKERS] New CRC algorithm: Slicing by 8
Tom Lane wrote: Yah, I checked. Several times... but if anyone else wants to repeat the experiment, please do. Or look for bugs in either my test case or Gurjeet's. FWIW - FreeBSD and Linux results using Tom's test program on almost identical hardware[1]: Std crc Slice-8 crc Intel P-III 1.26Ghz (FreeBSD 6.2) 8192 bytes 12.975314 14.503810 1024 bytes 1.6335571.852322 64 bytes0.1115800.206975 Intel P-III 1.26Ghz (Gentoo 2006.1) 8192 bytes 12.967997 28.363876 1024 bytes 1.6323173.626230 64 bytes0.1115130.326557 Interesting that the slice-8 algorithm seems to work noticeably better on FreeBSD than Linux - but still not as well as the standard one (for these tests anyway)... Cheers Mark [1] Both boxes have identical mobos, memory and CPUs (same sspec nos). ---(end of broadcast)--- TIP 5: don't forget to increase your free space map settings
Re: [HACKERS] New CRC algorithm: Slicing by 8
Mark Kirkwood [EMAIL PROTECTED] writes: Interesting that the slice-8 algorithm seems to work noticeably better on FreeBSD than Linux - Are you running similar gcc versions on both? I realize I forgot to document what I was using: HPPA: gcc version 2.95.3 20010315 (release) PPC: gcc version 4.0.1 (Apple Computer, Inc. build 5363) both Intels: gcc version 4.1.1 20060525 (Red Hat 4.1.1-1) Interesting that it's only the oldest-line tech that's showing a win for me ... regards, tom lane ---(end of broadcast)--- TIP 3: Have you checked our extensive FAQ? http://www.postgresql.org/docs/faq
