"=?gb18030?B?sKTM38jL?=" <2363541...@qq.com> writes:
> So, the question is, is there any way we can push join predicate into inner
> table ( we can disable merge join and hash join to get NL Join, but join
> predicate is not able to push into inner table )?
You probably need to turn on use_remo
Alex Turner wrote:
This is possible with Oracle utilizing the keep pool
alter table t_name storage ( buffer_pool keep);
If Postgres were to implement it's own caching system, this seems like
it would be easily to implement (beyond the initial caching effort).
Alex
On 10/24/05, Craig A. James
This is possible with Oracle utilizing the keep pool
alter table t_name storage ( buffer_pool keep);
If Postgres were to implement it's own caching system, this seems like
it would be easily to implement (beyond the initial caching effort).
Alex
On 10/24/05, Craig A. James <[EMAIL PROTECTED]>
Jim C. Nasby" wrote:
> Stefan Weiss wrote:
> ... IMO it would be useful to have a way to tell
> PG that some tables were needed frequently, and should be cached if
> possible. This would allow application developers to consider joins with
> these tables as "cheap", even when querying on columns
A blast from the past is forwarded below.
douglas
Begin forwarded message:
From: Tom Lane <[EMAIL PROTECTED]>
Date: August 23, 2005 3:23:43 PM EDT
To: Donald Courtney <[EMAIL PROTECTED]>
Cc: pgsql-performance@postgresql.org, Frank Wiles <[EMAIL PROTECTED]>, gokulnathbabu manoharan <[EMAIL PROTEC
From: Kevin Grittner <[EMAIL PROTECTED]>
Sent: Oct 5, 2005 2:16 AM
Subject: Re: [PERFORM] Is There Any Way
>First off, Mr. Trainor's response proves nothing about anyone or
>anything except Mr. Trainor.
>
Fair Enough. I apologize for the inappropriately general stateme
On Tue, 4 Oct 2005 23:06:54 -0400 (EDT)
Ron Peacetree <[EMAIL PROTECTED]> wrote:
> Then there's the large library of research on caching strategies
> in just about every HW and SW domain, including DB theory,
> that points put that the more context dependent, ie application
> or domain specific aw
** Low Priority **
Human feedback from testers and users has proven pretty effective
at catching errors in the "human assisted" cache configuration. When
people setting up the servers have missed the named cache configuration,
and all they had was the single general purpose cache, it has been cau
I'm sure there will be cases when some human assisted caching algorithm will
perform better than an mathetical statistical based design, but it will also
depend on the "human". And it probably will make thing worse when workload
changes and human doesn't realize. It must be considered that, today,
Hey, you can say what you want about my style, but you
still haven't pointed to even one article from the vast literature
that you claim supports your argument. And I did include a
smiley. Your original email that PostgreSQL is wrong and
that you are right led me to believe that you, like other
First off, Mr. Trainor's response proves nothing about anyone or
anything except Mr. Trainor.
I'm going to offer an opinion on the caching topic. I don't have
any benchmarks; I'm offering a general sense of the issue based on
decades of experience, so I'll give a short summary of that.
I've be
On Tue, Oct 04, 2005 at 11:06:54PM -0400, Ron Peacetree wrote:
> Unfortunately, no matter what I say or do, I'm not going to please
> or convince anyone who has already have made their minds up
> to the extent that they post comments like Mr Trainor's below.
> His response style pretty much proves
On Tue, Oct 04, 2005 at 11:06:54PM -0400, Ron Peacetree wrote:
> Some might even argue that IBM (where Codd and Date worked)
> and Oracle just _might_ have had justification for the huge effort
> they put into developing such infrastructure.
The OS and FS world is very, very different now than i
"Joshua D. Drake" <[EMAIL PROTECTED]>
Sent: Oct 4, 2005 9:32 PM
To: "Douglas J. Trainor" <[EMAIL PROTECTED]>
Cc: pgsql-performance@postgresql.org
Subject: Re: [PERFORM] Is There Any Way
Douglas J. Trainor wrote:
>
> Ron Peacetree sounds like someone talkin
Douglas J. Trainor wrote:
Ron Peacetree sounds like someone talking out of his _AZZ_.
He can save his unreferenced flapdoodle for his SQL Server
clients. Maybe he will post references so that we may all
learn at the feet of Master Peacetree. :-)
Although I agree that I would definitely like
al Message-
From: "Jim C. Nasby" <[EMAIL PROTECTED]>
Sent: Oct 4, 2005 4:57 PM
To: Stefan Weiss <[EMAIL PROTECTED]>
Cc: pgsql-performance@postgresql.org
Subject: Re: [PERFORM] Is There Any Way
On Tue, Oct 04, 2005 at 12:31:42PM +0200, Stefan Weiss wrote:
On 2005-09
On Tue, Oct 04, 2005 at 07:33:47PM -0400, Ron Peacetree wrote:
> pg is _very_ stupid about caching. Almost all of the caching is left
> to the OS, and it's that way by design (as post after post by TL has
> pointed out).
>
> That means pg has almost no ability to take application domain
> specifi
-Original Message-
From: "Jim C. Nasby" <[EMAIL PROTECTED]>
Sent: Oct 4, 2005 4:57 PM
To: Stefan Weiss <[EMAIL PROTECTED]>
Cc: pgsql-performance@postgresql.org
Subject: Re: [PERFORM] Is There Any Way
On Tue, Oct 04, 2005 at 12:31:42PM +0200, Stefan Weiss wro
of usage you are mentioning is exactly why I was
> asking.
>
> -Original Message-
> From: [EMAIL PROTECTED]
> [mailto:[EMAIL PROTECTED] Behalf Of Stefan Weiss
> Sent: Tuesday, October 04, 2005 6:32 AM
> To: pgsql-performance@postgresql.org
> Subject: Re:
On Tue, Oct 04, 2005 at 12:31:42PM +0200, Stefan Weiss wrote:
> On 2005-09-30 01:21, Lane Van Ingen wrote:
> > (3) Assure that a disk-based table is always in memory (outside of keeping
> > it in
> > memory buffers as a result of frequent activity which would prevent
> > LRU
> > opera
Yes, Stefan, the kind of usage you are mentioning is exactly why I was
asking.
-Original Message-
From: [EMAIL PROTECTED]
[mailto:[EMAIL PROTECTED] Behalf Of Stefan Weiss
Sent: Tuesday, October 04, 2005 6:32 AM
To: pgsql-performance@postgresql.org
Subject: Re: [PERFORM] Is There Any Way
On 2005-09-30 01:21, Lane Van Ingen wrote:
> (3) Assure that a disk-based table is always in memory (outside of keeping
> it in
> memory buffers as a result of frequent activity which would prevent
> LRU
> operations from taking it out) ?
I was wondering about this too. IMO it would
Lane Van Ingen wrote:
(2) Set up user variables in memory that are persistent across all
sessions, for
as long as the database is up and running ?
You could probably write "C" functions (or possibly Perl) to store data
in shared memory. Of course you'd have to deal with concurrency iss
On Thu, Sep 29, 2005 at 07:21:08PM -0400, Lane Van Ingen wrote:
> (1) Make a table memory-resident only ?
You might want to look into memcached, but it's impossible to say whether it
will fit your needs or not without more details.
/* Steinar */
--
Homepage: http://www.sesse.net/
Quoting Lane Van Ingen <[EMAIL PROTECTED]>:
> ... to do the following:
> (1) Make a table memory-resident only ?
Put it on a RAM filesystem. On Linux, shmfs. On *BSD, mfs. Solaris, tmpfs.
> (2) Set up user variables in memory that are persistent across all
> sessions, for
> as long
1) AFAIK, no. Just in case you are thinking "There should be a way coz I
know it will be used all the time", you must know that postgresql philosophy
is "I'm smarter than you". If table is used all the time, it will be in
memory, if not, it won't waste memory.
2) don't know.
3) see number 1) Of cou
26 matches
Mail list logo
