Philip Warner <[EMAIL PROTECTED]> writes:
> At 09:36 AM 2/11/2002 -0500, Tom Lane wrote:
>> BTW, the system does not actually have any stats about dead tuples.
>> What it knows about are live tuples and total disk pages occupied by
>> the table.
> So what made it choose the index scan?
Well, the
> I have just noticed that the implementation of
> CONVERT(text USING encoding_name)
> tries to do database access during the grammar phase, viz it looks
> up the encoding_name in pg_conversion and replaces it with an OID.
>
> This is not workable; consider the situation where we are in an
>
At 09:36 AM 2/11/2002 -0500, Tom Lane wrote:
Why not do frequent non-full vacuums on only that table, perhaps every
five minutes or so? That's certainly the direction that development is
headed in (we just haven't automated the vacuuming yet).
Done this now, and I'll wait for a new high load t
Is the missing const a major problem or can I save this patch for 7.4?
---
Tommi Mäkitalo wrote:
> Hi,
>
> I just discovered, that there is missing a const when passing a buffer to
> PQescapeBytea and PQunescapeBytea. I fi
Tom Lane wrote:
> Bruce Momjian <[EMAIL PROTECTED]> writes:
> > Tom Lane wrote:
> >> Bruce Momjian <[EMAIL PROTECTED]> writes:
> >>> I thought about that, but I need to fail if the cursor name is invalid.
> >>
> >> What has that got to do with it?
>
> > If I put the 'return' for 0 MOVE/FETCH in
Hello Tom,
Saturday, November 2, 2002, 5:17:29 PM, you wrote:
TL> Steve Howe <[EMAIL PROTECTED]> writes:
>> howe=# select p.oid, n.nspname, pg_get_userbyid(p.proowner), proname
>> from pg_proc as p, pg_namespace as n where pg_table_is_visible(p.oid);
>> However, this situation lead me into anoth
Hi,
I just discovered, that there is missing a const when passing a buffer to
PQescapeBytea and PQunescapeBytea. I fixed it and tried to create a usable
diff (I'm not so familar to diff).
Tommi
(resent with the right identity)
*** postgresql-7.3b3/src/interfaces/libpq/fe-exec.c 2002-09-04 22:
Steve Howe <[EMAIL PROTECTED]> writes:
> howe=# select p.oid, n.nspname, pg_get_userbyid(p.proowner), proname
> from pg_proc as p, pg_namespace as n where pg_table_is_visible(p.oid);
> However, this situation lead me into another issue. The new conversion
> functions (utf8_to_big5, iso_to_alt, etc
Hello Tom,
Saturday, November 2, 2002, 11:26:56 AM, you wrote:
TL> Steve Howe <[EMAIL PROTECTED]> writes:
>> I got a weird behavior testing PostgreSQL 7.3b3. The query below was
>> run in a FreeBSD 4.4 system, on a fresh install and just I just had
>> made an initb. No classes created at all.
>>
Hello,
attached are two files that are neccessary for the NetWare platform.
I think the patch files doesn't need any description because it
doesn't
change anything substantial.
The file netware.zip contains the files that should be stored at
/src/netware,
similar to the folder /src/win32. It con
On Sat, Nov 02, 2002 at 01:01:11 -0500,
Tom Lane <[EMAIL PROTECTED]> wrote:
>
> The example of a serial column (DEFAULT nextval('foo_seq')) seems
> compelling. You do not really want to grant general-purpose UPDATE
> rights on foo_seq to everyone you might allow to INSERT into your
> table.
If
I said:
> And I have not yet been able to think of a concrete case where the
> existing behavior (execute as calling user) is better.
Okay, I've thought of one: consider the situation where you want to
label each row in a table with the ID of the user who inserted it.
Right now, you can do
Bruce Momjian <[EMAIL PROTECTED]> writes:
> Tom Lane wrote:
>> Bruce Momjian <[EMAIL PROTECTED]> writes:
>>> I thought about that, but I need to fail if the cursor name is invalid.
>>
>> What has that got to do with it?
> If I put the 'return' for 0 MOVE/FETCH in utility.c's FetchStmt code, I
>
Philip Warner <[EMAIL PROTECTED]> writes:
> This comes about because we have a table with 800 rows, one more more of
> which are updated every second of most days. The result in normal usage is
> that the table contains about 1 tuples one hour after vacuuming. Also,
> the databases tries to
Philip Warner <[EMAIL PROTECTED]> writes:
> At 07:39 PM 2/11/2002 +1100, Philip Warner wrote:
> The latter time is actually quote good; when the machine is more
> heavily loaded it goes up to 1ms.
>
> We currently vacuum/analyze daily, and analyze hourly.
Why not vacuum hourly (regular non-
Steve Howe <[EMAIL PROTECTED]> writes:
> I got a weird behavior testing PostgreSQL 7.3b3. The query below was
> run in a FreeBSD 4.4 system, on a fresh install and just I just had
> made an initb. No classes created at all.
> howe=# select p.oid, n.nspname, pg_get_userbyid(p.proowner), proname
> f
On Sat, 2 Nov 2002, Tom Lane wrote:
> Bruce Momjian <[EMAIL PROTECTED]> writes:
> > Tom Lane wrote:
> >> Unfortunately, I don't see any way offhand to fix this without an
> >> initdb :-(.
>
> > Ooch, that hurts. How bad would it be if it was broken in 7.3?
>
> We could dike out the feature:
>
> c
At 07:39 PM 2/11/2002 +1100, Philip Warner wrote:
To give some numbers:
And some more numbers, directly after a vacuum and analyze:
mail=# explain analyze select * from often_updated where id between
'-1' and '10';
Index Scan using barnet_users_id on often_updated (cost=0.00..3095.66
The optimizer seems to know about dead rows in tables (ie. it will use an
index it would not ordinarily use if vacuum-full had been run, apparently
because it knows the table has many dead rows, and only a few valid ones.
I was wondering if there would any value in letting the optimizer replace
Hello all,
I got a weird behavior testing PostgreSQL 7.3b3. The query below was
run in a FreeBSD 4.4 system, on a fresh install and just I just had
made an initb. No classes created at all.
howe=# select p.oid, n.nspname, pg_get_userbyid(p.proowner), proname
from pg_proc as p, pg_namespace as n w
20 matches
Mail list logo
