SUSE's dvd includes PostgreSQL 7.4
and i think it's also avalable via ftp from various mirrors.
Search at Google, or at Novell site.
But if you search a newer version, i can't help you.
On Mon, 13 Jun 2005, martin wrote:
hi all
i try to find a new postgre rpm package for suse 9.2 but i
It's a fairly corner case feature, only for the case where you're
looking for the existance of an index key but don't want any other
data. I don't personally have any queries that could use such a
construct, though maybe I'm missing the point.
I understand the difficulty of implementation
Hi,
in case that one has a table R(att0 int4, att1 int4), an index on att1
and a query selecting only att1 whith a range condition over att1, then
the optimal access path for a rdbms would be INDEX ONLY SCAN, which means
scan only the index, and not the relation (all the needed information
As far as i can see, postgresql select a simple INDEX SCAN using index
on table.
That's because the index does not hold all the information. So INDEX
ONLY is impossible.
Thank you for your quick answer, but there is something a don't
understand:
the index holds all attributes' values
Visibility information. An index contains references to all rows in all
transactions. You need to go back to the table to work out if the row
is visible in your transaction.
Hope this helpsm
Yes at all.
You have a lot of work for future postgresql' versions :-))
All you said are wright. But it 's not so difficult for postgresql to hold
on a bit attribute attached to each table the information, whether there
is done an insertion/deletion/update to a clustered table or not.
And i guess, postgresql would already implement this simply alternative.
Easy,
On Tue, 1 Mar 2005, Tom Lane wrote:
Tatsuo Ishii [EMAIL PROTECTED] writes:
So it seems Ioannis' number was not taken immediately after a CREATE
INDEX operation?
I would guess not, but it's up to him to say. If it is a number derived
after some period of normal operation, then his
On Wed, 2 Mar 2005, Tatsuo Ishii wrote:
An other question:
Is there any way to prevent duplicates on btree index attribute,
PERMITTING them on table?
I can't think of any usefull usage for such an index. Can you explain
why you need it?
I have a relation like this: (att0
Hi,
I have created a btree index on a 'int4' attribute of a table.
After i have inserted 1,000,000 raws in my table, i can see that my index
size is 2745 Blocks (8KB each) from pg_class. That means about 21,960 KB
size.
I try to understand hows is this number generated, because thought that
Thanks a lot.
An other question:
Is there any way to prevent duplicates on btree index attribute,
PERMITTING them on table?
On Tue, 1 Mar 2005, Tatsuo Ishii wrote:
I have created a btree index on a 'int4' attribute of a table.
After i have inserted 1,000,000 raws in my table, i can
As far as i can see my mail was not sent to list. I forward it:
-- Forwarded message --
Date: Fri, 10 Dec 2004 05:15:42 +0200 (EET)
From: Ioannis Theoharis [EMAIL PROTECTED]
To: [EMAIL PROTECTED]
Subject: Clustering in the presence of hierarchies
I'd like to ask you about
I'd like to ask you about the clustering strategy that postgres
implements.
Exactly: I have created a hierachy of tables using 'inherits'
relationship. I have populated tables with a huge amount of data and then
I cluster each table according to an attribute that exists on Root table
(hence,
explain analyze to give the same response time at both cases. But
i found that time increases as where as the level, where data are located,
increases.
Can anybody explain me the reason?
On Sun, 22 Aug 2004, Tom Lane wrote:
Ioannis Theoharis [EMAIL PROTECTED] writes:
I expekt to find the same
13 matches
Mail list logo
