Tom Lane wrote:
"Florian G. Pflug" <[EMAIL PROTECTED]> writes:
Image a complex, autogenerated query with looks something like this
select
from t1
join t2 on ...
join t3 on ...
join t4 on ...
...
...
where
.
This big, complicated expression looks different for e
Peter Eisentraut wrote:
Arturo Pérez wrote:
The DBA therefore pokes the
right information into
the planner's statistical tables (or, perhaps, a more human-
manageable one that gets
"compiled" into the planner's stats).
I think we're perfectly capable of producing a system that can collect
the
Tom Lane wrote:
Simon Riggs <[EMAIL PROTECTED]> writes:
Revised patch enclosed, now believed to be production ready. This
implements regular log switching using the archive_timeout GUC.
Further patch enclosed implementing these changes plus the record type
version of pg_xlogfile_name_offset()
[EMAIL PROTECTED] wrote:
This is what I mean by after thought. PostgreSQL is designed for
32-bit processors. Which is fine. I'm not complaining. The question
was whether there is an interest in pursuing 64-bit specific
optimizations. In the PostgreSQL code, a quick check points me only to
"has lo
Jim C. Nasby wrote:
On Thu, Sep 28, 2006 at 03:07:39PM -0700, David Wheeler wrote:
PostgreSQLers,
I just ran into an issue where a client thought that autovacuum was
running but it wasn't. This is because it's not fatal when autovacuum
is on but stats_start_collector and/or stats_row_level
Tom Lane wrote:
Stephen Frost <[EMAIL PROTECTED]> writes:
* Tom Lane ([EMAIL PROTECTED]) wrote:
It looks like it should work to have just one polymorphic aggregate
definition, eg, array_accum(anyelement) returns anyarray.
I was hoping to do that, but since it's an aggregate the ffunc format
301 - 306 of 306 matches
Mail list logo
