Jim C. Nasby wrote:
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
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, th
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 d
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, 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
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 expec
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
the
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 fea
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 fea
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 Dunst
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.
--
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 b
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
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 i
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 form
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 SELEC
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.
http://pgfoundry.org
17 matches
Mail list logo
