Upon several requests of the master-slave patch source code, I sent it
here. This is a proof-of-concept implementation only to show it is
feasible only.
To play with it, applied it to cvs tip. When you key in a SQL like:
SELECT max(i) FROM t; // t with more than 20 records
You are s
Two quick announcements:
(1) I'm planning on taking the summer off from Postgres development (May
til the end of August). I'll be temporarily unsubscribing from the
mailing lists, but I'll be accessible via personal email, so feel free
to CC me on anything you'd like my input on.
(2) I'll be on v
Jim C. Nasby wrote:
On Fri, Mar 31, 2006 at 07:01:18PM -0500, Tom Lane wrote:
David Wheeler <[EMAIL PROTECTED]> writes:
Yes, but even the environment variables get me what I want. I
therefore respectfully submit the attached patch to document them in
the INSTALL file.
It seems rather pointl
Bruce Momjian wrote:
Andrew Dunstan wrote:
I don't know what unreasonable infrastructure you are referring to.
Building cvsup is a major pain, but installing and running it isn't, in
my experience. There's a package in Fedora Extras. Setting up cvsweb
against my cvsup repo is a fine idea
"Luke Lonergan" <[EMAIL PROTECTED]> writes:
> On 4/9/06 9:27 AM, "Tom Lane" <[EMAIL PROTECTED]> wrote:
>> 2. There are some low-level assumptions that no one reads in pages of
>> a relation without having some kind of lock on the relation (consider
>> eg the case where the relation is being dropped
On 4/9/06, Luke Lonergan <[EMAIL PROTECTED]> wrote:
> Gregory,
>
> On 4/9/06 1:36 PM, "Gregory Maxwell" <[EMAIL PROTECTED]> wrote:
>
> > It might also be interesting for someone with the right testing rig on
> > linux to try the adaptive
> > readahead patch to see if that improves PG's ability to k
Tom,
On 4/9/06 9:27 AM, "Tom Lane" <[EMAIL PROTECTED]> wrote:
> 2. There are some low-level assumptions that no one reads in pages of
> a relation without having some kind of lock on the relation (consider
> eg the case where the relation is being dropped). A bgwriter-like
> process wouldn't be
Gregory,
On 4/9/06 1:36 PM, "Gregory Maxwell" <[EMAIL PROTECTED]> wrote:
> It might also be interesting for someone with the right testing rig on
> linux to try the adaptive
> readahead patch to see if that improves PG's ability to keep the disk busy.
"the" adaptive readahead patch? Did I miss
Andrew Dunstan wrote:
> I don't know what unreasonable infrastructure you are referring to.
> Building cvsup is a major pain, but installing and running it isn't, in
> my experience. There's a package in Fedora Extras. Setting up cvsweb
> against my cvsup repo is a fine idea - I wonder why I did
On 4/9/06, Tom Lane <[EMAIL PROTECTED]> wrote:
> Certainly. If the OS has readahead logic at all, it ought to think that
> a seqscan of a large table qualifies. Your arguments seem to question
> whether readahead is useful at all --- but they would apply *just as
> well* to an app doing its own r
Myron,
On 4/9/06 1:18 PM, "[EMAIL PROTECTED]" <[EMAIL PROTECTED]> wrote:
> I am working with Solaris on SPARC almost exclusively and I believe Josh said
> that Sun was the one who found the bursty behavior with scans. Has it been
> confirmed that this is the case on all/most platforms?
It was o
I am working with Solaris on SPARC almost exclusively and I believe Josh said
that Sun was the one who found the bursty behavior with scans. Has it been
confirmed that this is the case on all/most platforms?
Myron Scott
-Original Message-
From: Tom Lane <[EMAIL PROTECTED]>
Subj: Re:
Jonah H. Harris wrote:
> On 4/9/06, Tom Lane <[EMAIL PROTECTED]> wrote:
> > Oh? Anything much above the level of bufmgr is going to be dependent on
> > relcache, syscache, etc, and those are all definitely database-specific.
> > You can't just retarget a backend to operate in another database, at
On 4/9/06, Tom Lane <[EMAIL PROTECTED]> wrote:
> Oh? Anything much above the level of bufmgr is going to be dependent on
> relcache, syscache, etc, and those are all definitely database-specific.
> You can't just retarget a backend to operate in another database, at
> least not without major chang
"Jonah H. Harris" <[EMAIL PROTECTED]> writes:
> The reader-like processes or "execution agents", whatever you want to
> call them, are limited to the postgres database only because they've
> been coded that way... but there's nothing that actually restricts
> them from being used for any database.
On 4/9/06, Tom Lane <[EMAIL PROTECTED]> wrote:
> That's not remotely the same thing: a backend is a very different animal
> from a bgwriter.
Yes, I know. Had I known it would've been picked apart, I would've
described it better.
> In particular, bgwriter (and bgreaders if we had 'em)
> aren't da
"Gregory Maxwell" <[EMAIL PROTECTED]> writes:
> On 4/9/06, Tom Lane <[EMAIL PROTECTED]> wrote:
>> So before we go inventing complicated bits of code with lots of added
>> overhead, we should first find out exactly why the system doesn't
>> already work the way it's supposed to.
> But is that reall
"Jonah H. Harris" <[EMAIL PROTECTED]> writes:
> On 4/9/06, Tom Lane <[EMAIL PROTECTED]> wrote:
>> I was considering a variant idea in the shower this morning:suppose
>> that we invent one or more "background reader" processes that have
>> basically the same infrastructure as the background writer,
On 4/9/06, Tom Lane <[EMAIL PROTECTED]> wrote:
> "Gregory Maxwell" <[EMAIL PROTECTED]> writes:
> > For example, one case made in this thread involved bursty performance
> > with seqscans presumably because the I/O was stalling while processing
> > was being performed.
>
> Actually, the question tha
On Apr 9, 2006, at 9:26 AM, Martijn van Oosterhout wrote:
On Sun, Apr 09, 2006 at 08:23:36AM -0700, Myron Scott wrote:
This is the part I'm curious about - is this using the
shared_buffers region
in a circular buffer fashion to store pre-fetched pages?
Yes. That is basically what the slave
On 4/9/06, Tom Lane <[EMAIL PROTECTED]> wrote:
> I was considering a variant idea in the shower this morning:suppose
> that we invent one or more "background reader" processes that have
> basically the same infrastructure as the background writer, but have
> the responsibility of causing buffer rea
"Gregory Maxwell" <[EMAIL PROTECTED]> writes:
> For example, one case made in this thread involved bursty performance
> with seqscans presumably because the I/O was stalling while processing
> was being performed.
Actually, the question that that raised in my mind is "why isn't the
kernel doing re
Myron Scott <[EMAIL PROTECTED]> writes:
> Gregory Maxwell wrote:
>> There are other cases where it is useful to perform parallel I/O
>> without parallel processing..
> I have done some testing more along these lines with an old fork of
> postgres code (2001). In my tests, I used a thread to deleg
On Sun, Apr 09, 2006 at 08:23:36AM -0700, Myron Scott wrote:
> >This is the part I'm curious about - is this using the
> >shared_buffers region
> >in a circular buffer fashion to store pre-fetched pages?
>
> Yes. That is basically what the slave thread is trying to do. As
> well as weed out
On Apr 8, 2006, at 10:29 PM, Luke Lonergan wrote:
Myron,
First, this sounds really good!
On 4/8/06 9:54 PM, "Myron Scott" <[EMAIL PROTECTED]> wrote:
I added a little hack to the buffer
code to force
pages read into the buffer to stay at the back of the free buffer
list
until the master
Hi Tom!
Am 09.04.2006 um 04:34 schrieb Tom Lane:
Philipp Ott <[EMAIL PROTECTED]> writes:
Currently 8.1.3 compiles and runs just fine on OSX 10.4.6 + XCode
2.2.1, but generates binaries just for the current host architecture.
Now when I add -arch i386 -arch ppc to CFLAGS and LDFLAGS for
config
"Tom Lane" <[EMAIL PROTECTED]> wrote
>
> This is exactly the bit of optimism I was questioning. We've already
> been sweating blood trying to reduce multiprocessor contention on data
> structures in which collisions ought to be avoidable (ie, buffer arrays
> where you hope not everyone is hitting
Ühel kenal päeval, L, 2006-04-08 kell 18:47, kirjutas Luke Lonergan:
> I agree - there is a real continuing need for overlapped scan and execution,
> though I'm not sure quite how to get it efficiently using inter-process
> communication. The AIO interface is nicely proven at this point, but to
>
28 matches
Mail list logo
