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
[ 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
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
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
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
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
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
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
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 -
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
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
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?
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
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
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,
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
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
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
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
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.
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
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
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
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
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
[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
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
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
28 matches
Mail list logo
