Thanks Tom and Gavin for your comments!
Yes, this patch is generated against 8.2 in a short time. As long as the
code is working, I post the patch to get some comments and help.
>>
>> * The xlog routines need help; they seem to not be updated for recent
>> changes in the API for xlog recovery c
On Mon, 24 Jul 2006, Mark Kirkwood wrote:
> Tom Lane wrote:
> > Mark Kirkwood <[EMAIL PROTECTED]> writes:
> >> Scale factor 10 produces an accounts table of about 130 Mb. Given that
> >> most HW these days has at least 1G of ram, this probably means not much
> >> retrieval IO is tested (only check
Tom Lane wrote:
Mark Kirkwood <[EMAIL PROTECTED]> writes:
Scale factor 10 produces an accounts table of about 130 Mb. Given that
most HW these days has at least 1G of ram, this probably means not much
retrieval IO is tested (only checkpoint and wal fsync). Do we want to
try 100 or even 200? (o
Mark Kirkwood <[EMAIL PROTECTED]> writes:
> Scale factor 10 produces an accounts table of about 130 Mb. Given that
> most HW these days has at least 1G of ram, this probably means not much
> retrieval IO is tested (only checkpoint and wal fsync). Do we want to
> try 100 or even 200? (or recommen
> 100 transactions seems barely enough to get through startup
> transients.
> Maybe 1000 would be good.
OK.
>
> I think the hard part of this is the reporting process. How
> do we track how performance varies over time? It doesn't
> seem very useful to compare different buildfarm members, b
Tom Lane wrote:
"Bort, Paul" <[EMAIL PROTECTED]> writes:
Andrew said I should solicit opinions as to what parameters to use. A
cursory search through the archives led me to pick a scaling factor of
10, 5 users, and 100 transactions.
100 transactions seems barely enough to get through startup t
SAKATA Tetsuo <[EMAIL PROTECTED]> writes:
> I'll be pleased if someone tell me the reason why
> when a table is clustered the toast table is not reindexed.
It's not obvious that those two things should be related. You can
reindex the toast table if you wish ...
regards, t
"Bort, Paul" <[EMAIL PROTECTED]> writes:
> Andrew said I should solicit opinions as to what parameters to use. A
> cursory search through the archives led me to pick a scaling factor of
> 10, 5 users, and 100 transactions.
100 transactions seems barely enough to get through startup transients.
May
-hackers,
With help from Andrew Dunstan, I'm adding the ability to do a pgbench
run after all of the other tests during a buildfarm run.
Andrew said I should solicit opinions as to what parameters to use. A
cursory search through the archives led me to pick a scaling factor of
10, 5 users, and 1
Tom Lane wrote:
Hmmm ... AFAICS this must mean that flushing the WAL data to disk
at transaction commit time takes (most of) 20 msec on your hardware.
Which still seems high --- on most modern disks that'd be at least two
disk revolutions, maybe more. What's the disk hardware you're testing
on,
Hi,
My name is Tetsuo Sakata.
Now, I'm checking the PostgreSQL's CLUSTER command.
(I read PostgreSQL 8.1.2.)
I found that when clustering a table the toast table associated with
the table is not reindexed.
( reindex_relation() is called while the parameter toast_too is set false.
For this param
Robert Lor <[EMAIL PROTECTED]> writes:
> Tom Lane wrote:
>> Yeah, those seem plausible, although the hold time for
>> CheckpointStartLock seems awfully high --- about 20 msec
>> per transaction. Are you using a nonzero commit_delay?
>>
> I didn't change commit_delay which defaults to zero.
Hmmm
> Alvaro Herrera wrote:
> > Bruce Momjian wrote:
> > > Mario Weilguni wrote:
> > > > Will this patch make it into 8.2?
> > > > http://archives.postgresql.org/pgsql-patches/2004-12/msg00228.php
> > > >
> > > > It's a really nice feature, would be extremly useful with tools like
> > > > pgpool.
> >
Peter Eisentraut wrote:
As I understand this, the probe file is compiled into some sort of
object file which is linked into the binary.
Correct.
So if we ever have probes
in other components, we'd probably want to have separate probe source
and object files for them. That would seem bett
Tom Lane wrote:
Yeah, those seem plausible, although the hold time for
CheckpointStartLock seems awfully high --- about 20 msec
per transaction. Are you using a nonzero commit_delay?
I didn't change commit_delay which defaults to zero.
Regards,
-Robert
---(end
Tom,
On 7/23/06 5:25 PM, "Tom Lane" <[EMAIL PROTECTED]> wrote:
> If the column is sufficiently low cardinality, you might as well just do
> a seqscan --- you'll be hitting most of the heap's pages anyway. I'm
> still waiting to be convinced that there's a sweet spot wide enough to
> justify supp
Gavin Sherry <[EMAIL PROTECTED]> writes:
> On Sun, 23 Jul 2006, Tom Lane wrote:
>> However, the main problem I've got with this is that a new index AM is a
>> pretty large burden, and no one's made the slightest effort to sell
>> pghackers on taking this on.
> For low cardinality sets, bitmaps gre
On Sun, 23 Jul 2006, Tom Lane wrote:
> Gavin Sherry <[EMAIL PROTECTED]> writes:
> > Is anyone else looking at this patch?
>
> It's on my list of things to look at, but so are a lot of other patches ;-)
>
> A couple of comments after a *very* fast scan through the patch:
>
> * The xlog routines nee
Tatsuo Ishii <[EMAIL PROTECTED]> writes:
>>> Interesting. We (some Japanese companies including SRA OSS,
>>> Inc. Japan) did some PG scalability testing using a Unisys's big 16
>>> (physical) CPU machine and found PG scales up to 8 CPUs. However
>>> beyond 8 CPU PG does not scale anymore. The resul
Gavin Sherry <[EMAIL PROTECTED]> writes:
> Is anyone else looking at this patch?
It's on my list of things to look at, but so are a lot of other patches ;-)
A couple of comments after a *very* fast scan through the patch:
* The xlog routines need help; they seem to not be updated for recent
chan
On Saturday 22 July 2006 18:16, Christopher Browne wrote:
> Quoth Markus Schiltknecht <[EMAIL PROTECTED]>:
> > at the code sprint, we agreed to put together some documentation about
> > current and upcoming replication solutions for PostgreSQL. Is somebody
> > already working on that?
>
> I don't r
On Mon, 17 Jul 2006, Jie Zhang wrote:
> Hi,
>
> I have posted a patch to the CVS head for on-disk bitmap index to
> pgsql-patches. If this can get in 8.2, that would be great. Any comments and
> suggestions are welcome.
>
> I still need to add several items:
>
> (1) README file in src/backend/acce
Robert Lor wrote:
> Regarding where to put probe.d, will src/probe.d work since probes
> for all subsystems will go into this one file.
As I understand this, the probe file is compiled into some sort of
object file which is linked into the binary. So if we ever have probes
in other components,
Robert Lor <[EMAIL PROTECTED]> writes:
> Here is the break down between exclusive & shared LWLocks. Do the
> numbers look reasonable to you?
Yeah, those seem plausible, although the hold time for
CheckpointStartLock seems awfully high --- about 20 msec
per transaction. Are you using a nonzero co
Andrew Dunstan <[EMAIL PROTECTED]> writes:
> I see that pg_regress.c has the following (after I adjusted the #ifdef):
> /*
> * On Windows, it seems to be necessary to adjust PATH even in
> * this case. (XXX really? If so, what if installation has
> * been reloc
I see that pg_regress.c has the following (after I adjusted the #ifdef):
/*
* On Windows, it seems to be necessary to adjust PATH even in
* this case. (XXX really? If so, what if installation has
* been relocated?)
*/
#if defined(WIN32) || defined(CYGWIN
26 matches
Mail list logo
