Is pg_comparator the only project out there that does what it does? I
tried patching it, and it seems OK, but I'm not terribly confident in
my patch. I'm hoping someone will tell me there's a great table-
driven rsync out there that everyone uses and I just don't know
about.
On Fri, 2007-05-11 at 22:59 +0100, Heikki Linnakangas wrote:
For comparison, here's the test results with vanilla CVS HEAD:
copy-head | 00:06:21.533137
copy-head | 00:05:54.141285
I'm slightly worried that the results for COPY aren't anywhere near as
good as the SELECT
Hi Simon,
On 5/12/07 12:35 AM, Simon Riggs [EMAIL PROTECTED] wrote:
I'm slightly worried that the results for COPY aren't anywhere near as
good as the SELECT and VACUUM results. It isn't clear from those numbers
that the benefit really is significant.
COPY is bottlenecked on datum formation
The use of ActiveSnapshot throughout the code appears rather dangerous
to me. It is a global pointer, assumed not to be set yet in some places,
assumed to be saved and restored by the caller in others. The actual
(context) memory it points to is sometimes explicitly freed, sometimes
just left
Moving to -hackers.
On Fri, May 11, 2007 at 04:37:44PM +0100, Heikki Linnakangas wrote:
If you know when the checkpoint ended, and you know how long each of the
pieces took, you can reconstruct the other times easily. The way you
describe this it is true--that the summary is redundant given
Not to beat a dead horse, but do we really want to force folks to be
parsing logs for performance monitoring? Especially if that log parsing
is just going to result in data being inserted into a table anyway?
I know there's concern about performance of the stats system and maybe
that needs to
I returned on Wednesday from my trip to Australia and India. (I skipped
London.) I returned early because my brother-in-law died on May 5 (for
details see http://momjian.us/main/news.html).
Anyway, I am slow catching up on email for that reason. I should be
caught up by Tuesday/Wednesday.
--
Added to TODO:
o Allow data to be passed in native language formats, rather
than only text
http://archives.postgresql.org/pgsql-hackers/2007-05/msg00289$
---
Andrew
Jim Nasby wrote:
On May 6, 2007, at 8:18 AM, Andrew Dunstan wrote:
Oh, the answer to Bruce's question about when to create a feature
item? You could well do it at the time when today you create a TODO
item. However, we might even do better. For example, we might well
add feature
Jim Nasby wrote:
On May 6, 2007, at 8:18 AM, Andrew Dunstan wrote:
Oh, the answer to Bruce's question about when to create a feature
item? You could well do it at the time when today you create a TODO
item. However, we might even do better. For example, we might well
add feature
To follow up on Andrew's idea of tracking things back to the TODO or bug
number:
We could have a universal developer number, something like PGD#23432 as
a PostgreSQL Developer number. We could assign them for submissions to
the bugs list, where we already assign a number. I could easily add
On Sat, 12 May 2007, Jim C. Nasby wrote:
Not to beat a dead horse, but do we really want to force folks to be
parsing logs for performance monitoring?
All of the really interesting DBA level information about checkpoints is
now sitting in pg_stat_bgwriter. There really is no reason I'd
On Sat, 12 May 2007, Joshua D. Drake wrote:
One thing that doesn't seemed to be being looked at it is the cost of
logging.
If any of this executed at something like the query level, sure, that
would be real important. The majority of the logging I suggested here is
of things that happen at
The last two runs on baiji have failed at the installcheck stage,
with symptoms that look a heck of a lot like the most recent system
catalog changes haven't taken effect (eg, it doesn't seem to know
about pg_type.typarray). Given that the previous check step
passed, the most likely explanation
On Sat, 2007-12-05 at 14:26 -0700, Joshua D. Drake wrote:
Either way, we are taking the hit, it is just a matter of where. IMO it
would be better to have the information in the database where it makes
sense, than pushing out to a log
If performance monitoring information is provided as a
Tom Lane wrote:
The last two runs on baiji have failed at the installcheck stage,
with symptoms that look a heck of a lot like the most recent system
catalog changes haven't taken effect (eg, it doesn't seem to know
about pg_type.typarray). Given that the previous check step
passed, the most
16 matches
Mail list logo
