Hi Tom,
(B
(B> This "latches" stuff is irrelevant to us.
(B
(BWell, that's good to know anyway, thanks for setting me straight. Maybe
(BOracle could take a leaf out of PGs book instead of the other way around. I
(Brecall that you mentioned the caching of the schema before, so even though I
(
"Iain" <[EMAIL PROTECTED]> writes:
> I can only tell you (roughly) how it works wth Oracle,
Which unfortunately has little to do with how it works with Postgres.
This "latches" stuff is irrelevant to us.
In practice, any repetitive planning in PG is going to be consulting
catalog rows that it dra
Jim,
I can only tell you (roughly) how it works wth Oracle, and it's a very well
documented and laboured point over there - it's the cornerstone of Oracle's
scalability architecture, so if you don't believe me, or my explanation is
just plain lacking, then it wouldn't be a bad idea to check it out
Neil Conway wrote:
On Tue, 2004-09-28 at 08:42, Gaetano Mendola wrote:
Now I'm reading an article, written by the same author that ispired the magic "300"
on analyze.c, about "Self-tuning Histograms". If this is implemented, I understood
we can take rid of "vacuum analyze" for mantain up to date th
On Tue, 2004-09-28 at 08:42, Gaetano Mendola wrote:
> Now I'm reading an article, written by the same author that ispired the magic "300"
> on analyze.c, about "Self-tuning Histograms". If this is implemented, I understood
> we can take rid of "vacuum analyze" for mantain up to date the statistics.
Tom Lane wrote:
Gregory Stark <[EMAIL PROTECTED]> writes:
No, actually the stats table keeps the n most common values and their
frequency (usually in percentage). So really a target of 2 ought to be enough
for boolean values. In fact that's all I see in pg_statistic; I'm assuming
there's a full his
Any competently written application where caching results would be a
suitable performance boost can already implement application or
middleware caching fairly easily, and increase performance much more
than putting result caching into the database would.
I guess the performance increase is that
More to the point though, I think this is a feature that really really
should be in the DB, because then it's trivial for people to use.
How does putting it into PGPool make it any less trivial for people to
use?
The answers are atÂ
http://www2b.biglobe.ne.jp/~caco/pgpoo
On Mon, Sep 27, 2004 at 09:19:12PM +0100, Matt Clark wrote:
> >Basically you set a default in seconds for the HTML results to be
> >cached, and then have triggers set that force the cache to regenerate
> >(whenever CRUD happens to the content, for example).
> >
> >Can't speak for Perl/Python/Ruby/
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Josh Berkus wrote:
| Gaetano,
|
|
|>don't you think the best statistic target for a boolean
|>column is something like 2? Or in general the is useless
|>have a statistics target > data type cardinality ?
|
|
| It depends, really, on the proportionality
> More to the point though, I think this is a feature that really really
> should be in the DB, because then it's trivial for people to use.
How does putting it into PGPool make it any less trivial for people to
use?
---(end of broadcast)---
TIP
It might be easiest to shove the caching logic into pgpool instead.
...
When pg_pool is told to cache a query, it can get a table list and
monitor for changes. When it gets changes, simply dumps the cache.
It's certainly the case that the typical web app (which, along with
warehouses, seems to
Basically you set a default in seconds for the HTML results to be
cached, and then have triggers set that force the cache to regenerate
(whenever CRUD happens to the content, for example).
Can't speak for Perl/Python/Ruby/.Net/Java, but Cache_Lite sure made a
believer out of me!
Nice to have it
Gregory Stark <[EMAIL PROTECTED]> writes:
> No, actually the stats table keeps the n most common values and their
> frequency (usually in percentage). So really a target of 2 ought to be enough
> for boolean values. In fact that's all I see in pg_statistic; I'm assuming
> there's a full histogram s
Gaetano,
> don't you think the best statistic target for a boolean
> column is something like 2? Or in general the is useless
> have a statistics target > data type cardinality ?
It depends, really, on the proportionality of the boolean values; if they're
about equal, I certainly wouldn't raise
On Thu, Sep 23, 2004 at 08:29:25AM -0700, Mr Pink wrote:
> Not knowing anything about the internals of pg, I don't know how this relates, but
> in theory,
> query plan caching is not just about saving time re-planning queries, it's about
> scalability.
> Optimizing queries requires shared locks
> Gaetano,
>
> > don't you think the best statistic target for a boolean
> > column is something like 2? Or in general the is useless
> > have a statistics target > data type cardinality ?
>
> It depends, really, on the proportionality of the boolean values; if they're
> about equal, I certain
On Mon, 27 Sep 2004 18:20:48 +0100, Matt Clark <[EMAIL PROTECTED]> wrote:
> This is very true. Client side caching is an enormous win for apps, but it
> requires quite a lot of logic, triggers to update last-modified fields on
> relevant tables, etc etc. Moving some of this logic to the DB would
[ discussion of server side result caching ]
and lets not forget PG's major fork it will throw into things: MVCC
The results of query A may hold true for txn 1, but not txn 2 and so on
.
That would have to be taken into account as well and would greatly
complicate things.
It is always possible
19 matches
Mail list logo
