On Wed, 2005-05-18 at 17:48 -0400, Tom Lane wrote:
Simon Riggs [EMAIL PROTECTED] writes:
Is there any particular reason that RelOptInfo doesn't have a debugging
output function?
The planner structs involving RelOptInfo are self-referential, so if you
just do the obvious thing you will
On Wed, 18 May 2005, Tom Lane wrote:
* The major missing issue that I've come across so far is that
subtransaction and multixact state isn't preserved across a crash.
Assuming that we want to store only top-level XIDs in the shared-memory
list of prepared XIDs (which I think is important), it is
Hi Guys,
I was wondering whether there's still need for people doing translations
English - German ... I'd like to contribute but am not too fit in C
programming, didn't do anything in ages...
If this is the wrong place to ask, disregard this message :)
I couldn't find any more suitable
Tom,
I noticed that along with many improvements in join operations bitmap
index speed up execution of first time query. It's known complain about
slow full text searching when query runs for the first time. But in CVS
version I see very nice behaviour I'd like to understand.
Query below is full
yOn Thu, 19 May 2005, Oleg Bartunov wrote:
Tom,
I noticed that along with many improvements in join operations bitmap
index speed up execution of first time query. It's known complain about
slow full text searching when query runs for the first time. But in CVS
version I see very nice behaviour
Incrementing random_page_cost from 4 (the default) to 5 causes the
planner to make a better decision.
We have such a low default random_page_cost primarily to mask other
problems in the optimizer, two of which are
. multi-column index correlation
. interpolation between min_IO_Cost
But to get the estimated cost ratio to match up with the actual cost
ratio, we'd have to raise random_page_cost to nearly 70, which is a bit
hard to credit. What was the platform being tested here?
Why ? Numbers for modern single disks are 1-2Mb/s 8k random and 50-120 Mb/s
sequential.
I have a customer with the following error.
rpm -Uvh *.rpm
warning: postgresql-8.0.2-1PGDG.i686.rpm: V3 DSA signature: NOKEY, key
ID 748f7d0e
error: Failed dependencies:
libpq.so.3 is needed by postgresql-contrib-8.0.2-1PGDG
libecpg.so.4 is needed by postgresql-libs-8.0.2-1PGDG
[EMAIL PROTECTED] (Stephen Frost) writes:
* Tom Lane ([EMAIL PROTECTED]) wrote:
I think most of the real advantages of bug trackers that have been
mentioned in this thread have to do with history and searchability.
We have the raw info for that, in the pgsql-bugs and
pgsql-commmitters mail
Dave Cramer [EMAIL PROTECTED] writes:
I have a customer with the following error.
rpm -Uvh *.rpm
warning: postgresql-8.0.2-1PGDG.i686.rpm: V3 DSA signature: NOKEY, key
ID 748f7d0e
error: Failed dependencies:
libpq.so.3 is needed by postgresql-contrib-8.0.2-1PGDG
libecpg.so.4
Hi,
On 5/19/05, Tom Lane [EMAIL PROTECTED] wrote:
8.0.2 and up should provide/require libpq.so.4 and so on. Apparently
there is something broken with this set of RPMs.
For futher of the discussion:
http://lists.pgfoundry.org/pipermail/pgsqlrpms-hackers/2005-April/000197.html
Andrej,
I was wondering whether there's still need for people doing translations
English - German ... I'd like to contribute but am not too fit in C
programming, didn't do anything in ages...
We can always use translators.I lead a translator crew for PR materials,
and Peter (who is on
Oleg Bartunov oleg@sai.msu.su writes:
I tried to see io statistics, but it was weird in 8.0X and in 8.1dev I still
don't understand it :)
We aren't yet updating the io statistics for bitmap scans properly.
There was a thread about this but it petered out without any resolution
about what we
Heikki Linnakangas [EMAIL PROTECTED] writes:
As Alvaro pointed out elsewhere, the multixacts are harder because a
backend doesn't know which multixactids it belongs to. AFAICS, the most
straightforward solution is to xlog every CreateMultixact call, so that
the multixact slru files can be
Hello hackers
At the moment I need to pass from a SQL array to a C array.
I have the following table:
CREATE TABLE emps
(
name text,
array int4[]
)
For example, array have this values: {4000,1,0,0}
I wrote this function for test in order to see something that could help me:
extern
On Thu, 19 May 2005, Tom Lane wrote:
Oleg Bartunov oleg@sai.msu.su writes:
I tried to see io statistics, but it was weird in 8.0X and in 8.1dev I still
don't understand it :)
We aren't yet updating the io statistics for bitmap scans properly.
There was a thread about this but it petered out
Berend Tober [EMAIL PROTECTED] writes:
Now what, oh most wise one?
OK, now I finally get the point: you are creating child tables in
different schemas than their parents live in. This creates a problem
because reverse-listing of the constraints varies depending on what
the search path is.
An
Hello all,
I think that this patch is useful to decide when to vacuum.
It notifies when freespace empties as follows:
$ ./pgbench -i
$ ./pgbench -n -t 1000
LOG: FreeSpace for public.accounts becomes empty. (stored=1, avg=159,
min=128)
LOG: FreeSpace for public.tellers becomes empty.
18 matches
Mail list logo
