Tom Lane [EMAIL PROTECTED] writes:
Greg Stark [EMAIL PROTECTED] writes:
If the planner had the expected value as well as the variance of the cost
distribution then it might realize that in this case for instance that the
penalty for guessing wrong with an index scan is only going to be a
Greg Stark [EMAIL PROTECTED] writes:
Tom Lane [EMAIL PROTECTED] writes:
select * from mytable where entry_time = $1;
The planner will take a seqscan when it sees this because it is worried
about the downside if a large fraction of the table is being selected.
I'll mention another
Anyone thought about this at all yet? Is it possible to have
per-database variables that refer to the current database in someway
that would need to be altered to refer to the new db?
Chris
Christopher Kings-Lynne wrote:
Hi,
When you do this:
CREATE DATABASE test TEMPLATE master;
It doesn't
This weekend I am trying to fix up all known the pg_autovacuum issues
that should be resolved for 7.4.3. I am aware of only two issues: temp
table issues, and unchecked send_query() calls, if I am forgetting
something, please let me know.
1) temp table issue:
I was not able to reproduce the
Dear Carl,
What is the purpose of the extension api in simple terms; what is it FOR?
What does it DO?
Thanks for this perfectly legitimate question, as my mail was not very
easy to understand without the context.
The aim is to provide a compilation infrastructure to external modules
(that is
Dear Tom,
Agreed. If we are pushing things out, it seems it is our duty to make
it easy for outside things to integrate and build properly.
It does not thereby follow that we should try to merge devel and base
packages (to express it in RPM terms).
They are not necessarily merged, and
With current sources, it appears that vpath builds (i.e. separate source
and build trees) are broken. make succeeds, but make install produces:
[neilc:/Users/neilc/build-pgsql]% make install
make -C doc install
make[1]: Nothing to be done for `install'.
make -C src install
make -C port install
Robert Treat wrote:
Given that the cygwin version is currently labeled as not ready for
production I would say you are right. The truth is that many will never
declare win32 good for production simply because of the OS it runs on,
but we still want to make it as solid as possible.
People _do_ use
