* [EMAIL PROTECTED] [EMAIL PROTECTED] [000926 02:33] wrote:
Hello,
I recently spoke about extending index scan to be able
to take data directly from index pages.
[snip]
Is someone interested in this ??
Considering the speedup, I sure as hell am interested. :)
When are we going to have
At 12:28 26/09/00 +0300, Hannu Krosing wrote:
TODO:
- add HeapTupleHeaderData into each IndexTupleData
- change code to reflect above
- when deleting-updating heap then also update tuples'
HeapTupleHeaderData in indices
I doubt everyone would like trading query speed for insert/update
I'm thinking about changing the way that access permission checks are
handled for rules. The rule mechanism provides that accesses to tables
that are mentioned within rules are done with the permissions of the
rule owner, not the invoking user. The way this is implemented is that
when a rule is
I remember a post about 2 weeks back concerning a new patch that was to
be introduced as 7.0.3. I haven't seen any reference to this since then.
Is this still happening, or will the patch be part of 7.1?
-Tony Reina
tom is looking into a bug right now that he wants to try and fix before we
release it ... hopefully this week we'll release it ...
On Tue, 26 Sep 2000, G. Anthony Reina wrote:
I remember a post about 2 weeks back concerning a new patch that was to
be introduced as 7.0.3. I haven't seen any
Can someone add something to the docs that gives an example of what should
be used from the command line to reindex a database's system tables?
All the man page says is use th e-O an d-P options :(
I'm getting:
psql -h pgsql horde
ERROR: cannot read block 6 of pg_attribute_relid_attnam_index
Thomas Lockhart wrote:
Short Description
7.0.2 source rpm failed to compile
Long Description
I'm running RedHat 6.2 SPARC, two processors, 128 MB RAM
I downloaded postgresql-7.0.2-2.src.rpm from your main FTP site and tried 'rpm
--rebuild postgresql-7.0.2-2.src.rpm', it ran fine for
The last step could be done in two ways. First by limiting
number of indices for one table we can store coresponding
indices' TIDs in each heap tuple. The update is then simple
taking one disk write.
Why limit it ? One could just save an tid array in each tuple .
And update *entire*
Why not implement *true* CLUSTER?
With cluster, all heap tuples will be in cluster index.
Vadim
-Original Message-
From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]]
Sent: Tuesday, September 26, 2000 2:15 AM
To: [EMAIL PROTECTED]
Subject: [HACKERS] pgsql is 75 times faster with my
I've tried:
bin/postgres -O -P -D `pwd`/data horde
POSTGRES backend interactive interface
$Revision: 1.155.2.1 $ $Date: 2000/08/30 21:19:32 $
backend reindex database horde;
backend
still get it ...
I'm either doing something wrong with REINDEXng the system
tables, or this
-Original Message-
From: [EMAIL PROTECTED]
The Hermit Hacker
Can someone add something to the docs that gives an example of what should
be used from the command line to reindex a database's system tables?
All the man page says is use th e-O an d-P options :(
I'm getting:
psql
It looks like you are suffering from actual hardware failures:
%cd /pgsql/data/base/horde
%ls -l pg_attribute_relid_attnam_index
-rw--- 1 pgsql pgsql 65536 Aug 21 12:27 pg_attribute_relid_attnam_index
%wc pg_attribute_relid_attnam_index
wc: pg_attribute_relid_attnam_index: read:
I get an error (which is good). But, if I do
#BEGIN;
#SELECT * FROM name_and_ip WHERE name = 'foo' OR name = 'bar' FOR
UPDATE;
#UPDATE name_and_ip SET ip = '192.168.186.249' where name = 'foo';
UPDATE 1
#COMMIT;
COMMIT
Btree doesn't take into account that tuple was just marked
Jarmo Paavilainen wrote:
...
Is there a way to make postgre insensitive about field name cases?
Like
"initdb --fields-are-case-insensitive --compares-are-case-insensitive"
...
The main problem I see with case-insensitivity is the fact that there
are always more than one way to
Hannu Krosing [EMAIL PROTECTED] writes:
Can anyone explain why I must make / a character class
in case-insensitive query in order to match / ?
What LOCALE are you using? There was a thread about strange ordering
rules confusing the LIKE/regexp optimizer recently ...
Wow, has this been just one of those days ...
Trying to clean up a few of the database, I'm wondering how to fix some of
these things, if its even possible, without having to rebuild the whole
database:
%~/bin/postgres -O -P -D/pgsql/special/sales.org swissre
DEBUG: Data Base System is
figuring I'd try out getting into the backend using postgres, to see if I
can 'bypass' some of the errors on those corrupted database, I'm wondering
if there is any way of taking what a 'select * from table' outputs:
1: userid = "cibc001154" (typeid = 1043, len = -1, typmod = 36,
"Mikheev, Vadim" wrote:
Btree doesn't take into account that tuple was just marked
for update but still alive. Seems it was handled properly in 6.5.X ?
Nope. It has been broken a long time...
Hmm, as I remember, Hiroshi fixed something in this area for 7.0.X.
Hiroshi?
Probably,
Hmm,it seems that both current and REL7_0_PATCHES
have already been changed.
I committed the the change to current tree and
asked Tatsuo to commit it to REL7_0_PATCHES tree.
I also committed current -:))
Vadim
Short Description
7.0.2 source rpm failed to compile
Long Description
I'm running RedHat 6.2 SPARC, two processors, 128 MB RAM
I downloaded postgresql-7.0.2-2.src.rpm from your main FTP site and tried 'rpm
--rebuild postgresql-7.0.2-2.src.rpm', it ran fine for a long time but then exited
20 matches
Mail list logo
