Hi, there is a feature that I would be glad if it was supported by
PostgreSQL:
I want to add a new column (attribute) to a pre-existed table, but instead
of filling the values of this column with a default value (e.g. null) I
would like to copy them from a file stored in my filesystem.
I didn't
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 d
>
> 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 implementat
>
> 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 :-))
---
> >
> > 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 attribu
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
exi
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 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 v
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
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
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
fo
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 as
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, th
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 exp
14 matches
Mail list logo
