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. (store
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
On Thu, 19 May 2005, Tom Lane wrote:
Oleg Bartunov 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 resolutio
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 Datum
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
Oleg Bartunov 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 should do ...
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 o
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
-
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
>libec
[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
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
l
> 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.
An
> >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_
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 I'd
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 te
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 refer
16 matches
Mail list logo
