Josh Berkus <[EMAIL PROTECTED]> writes:
> Actually, 32 made a significant difference as I recall ... do you still have
> the figures for that, Jignesh?
I'd want to see a new set of test runs backing up any call for a change
in NUM_CLOG_BUFFERS --- we've changed enough stuff around this area that
Tom,
> It's still true that I'm leery of a large increase in the number of
> buffers without reengineering slru.c. That code was written on the
> assumption that there were few enough buffers that a linear search
> would be fine. I'd hold still for 16, or maybe even 32, but I dunno
> how much im
Gregory Stark <[EMAIL PROTECTED]> writes:
> Didn't we already go through this? He and Simon were pushing to bump up
> NUM_CLOG_BUFFERS and you were arguing that the test wasn't representative and
> some other clog.c would have to be reengineered to scale well to larger
> values.
AFAIR we never di
"Tom Lane" <[EMAIL PROTECTED]> writes:
> "Jignesh K. Shah" <[EMAIL PROTECTED]> writes:
>> CLOG data is
>> not cached in any PostgreSQL shared memory segments
>
> The above statement is utterly false, so your trace seems to indicate
> something broken. Are you sure these were the only reads of pg
"Jignesh K. Shah" <[EMAIL PROTECTED]> writes:
> CLOG data is not cached in any PostgreSQL shared memory segments and hence
> becomes the bottleneck as it has to constantly go to the filesystem to get
> the read data.
This is the same bottleneck you discussed earlier. CLOG reads are cached in
the
[EMAIL PROTECTED] (Jean-David Beyer) writes:
> Chris Browne wrote:
>> [EMAIL PROTECTED] (Jean-David Beyer) writes:
>>> But what is the limitation on such a thing? In this case, I am just
>>> populating the database and there are no other users at such a time. I am
>>> willing to lose the whole inse
"Jignesh K. Shah" <[EMAIL PROTECTED]> writes:
> CLOG data is
> not cached in any PostgreSQL shared memory segments
The above statement is utterly false, so your trace seems to indicate
something broken. Are you sure these were the only reads of pg_clog
files? Can you extend the tracing to deter
I thought I will update this to the Performance alias too about our
testing with PG8.3beta1 on Solaris.
Regards,
Jignesh
__Background_:_
We were using PostgreSQL 8.3beta1 testing on our latest Sun SPARC
Enterprise T5220 Server using Solaris 10 8/07. Generally for performance
benefits in Solar
Update on my testing 8.3beta1 on Solaris.
* CLOG reads
* Asynchronous Commit benefit
* Hot CPU Utilization
Regards,
Jignesh
__Background_:_
We were using PostgreSQL 8.3beta1 testing on our latest Sun SPARC
Enterprise T5220 Server using Solaris 10 8/07 and Sun Fire X4200 using
Solaris 10 8/07.
Chris Browne wrote:
> [EMAIL PROTECTED] (Jean-David Beyer) writes:
>> But what is the limitation on such a thing? In this case, I am just
>> populating the database and there are no other users at such a time. I am
>> willing to lose the whole insert of a file if something goes wrong -- I
>> would
[EMAIL PROTECTED] (Jean-David Beyer) writes:
> But what is the limitation on such a thing? In this case, I am just
> populating the database and there are no other users at such a time. I am
> willing to lose the whole insert of a file if something goes wrong -- I
> would fix whatever went wrong an
Jean-David Beyer <[EMAIL PROTECTED]> writes:
> But what is the limitation on such a thing?
AFAIR, the only limit on the size of a transaction is 2^32 commands
(due to CommandCounter being 32 bits).
regards, tom lane
---(end of broadcast)---
Jean-David Beyer wrote:
> This means, of course, that the things I think of as transactions have been
> bunched into a much smaller number of what postgreSQL thinks of as large
> transactions, since there is only one per file rather than one per record.
> Now if a file has several thousand records,
I have just changed around some programs that ran too slowly (too much time
in io-wait) and they speeded up greatly. This was not unexpected, but I
wonder about the limitations.
By transaction, I mean a single INSERT or a few related INSERTs.
What I used to do is roughly like this:
for each file
On Oct 25, 2007, at 10:30 AM, Jean-David Beyer wrote:
I have just changed around some programs that ran too slowly (too
much time
in io-wait) and they speeded up greatly. This was not unexpected,
but I
wonder about the limitations.
By transaction, I mean a single INSERT or a few related INS
15 matches
Mail list logo
