Andrew Chernow <[EMAIL PROTECTED]> writes:
> Here is the lastest pgparam patch. It is patched against a fresh
> checkout on 2007-12-05.
What is this for? Why is it a good idea? It appears to be a fairly
enormous increase in the size of libpq's API, and I really don't think
I want to buy into t
Tom Lane wrote:
Andrew Chernow <[EMAIL PROTECTED]> writes:
Here is the lastest pgparam patch. It is patched against a fresh
checkout on 2007-12-05.
What is this for? Why is it a good idea? It appears to be a fairly
enormous increase in the size of libpq's API, and I really don't think
I wan
On Dec 6, 2007 11:58 AM, Tom Lane <[EMAIL PROTECTED]> wrote:
> I want to buy into the idea that libpq should know explicitly about each
> and every backend datatype.
I don' t necessarily agree with this. First of all, the server gives
you an oid for the column which introduces the dependency...th
On Wed, 2007-12-05 at 15:13 -0500, Chris Browne wrote:
> I have the theory (thus far not borne out by any numbers) that it
> might be a useful approach to try to go through the DB schema and use
> what information is there to try to come up with better numbers on a
> per-column basis.
Yeh, agreed
There was some discussion earlier today
http://archives.postgresql.org/pgsql-performance/2007-12/msg00081.php
about how mergejoin cost estimation is not smart about the situation
where we will have to scan a lot of rows on one side of the join before
reaching the range of values found on the other
Rgds,
Arul Shaji
*** pgstandby.sgml 2007-12-06 14:52:18.0 +1100
--- new_pgstandby.sgml 2007-12-07 18:38:26.0 +1100
***
*** 262,268
keep the last 255 full WAL files, plus the current one
sleep for 2 seconds between checks for next WAL file is full
