Quoting Martijn van Oosterhout <[EMAIL PROTECTED]>:
> Annoying, not really. It's actually extremely useful. It's useful having a
> value which is never equal to anything else, not even itself. If you use it
> to represent "unknown" it will work for you. If you try to use it for
> anything else, it
On Thu, 1 Jan 2004, Tom Lane wrote:
> "Marc G. Fournier" <[EMAIL PROTECTED]> writes:
> > I take it there is no way of drop'ng OIDs after the fact, eh? :)
>
> I think we have an ALTER TABLE DROP OIDS command, but it won't instantly
> remove the OIDS from the table --- removal happens incrementally
"Marc G. Fournier" <[EMAIL PROTECTED]> writes:
> I take it there is no way of drop'ng OIDs after the fact, eh? :)
I think we have an ALTER TABLE DROP OIDS command, but it won't instantly
remove the OIDS from the table --- removal happens incrementally as rows
get updated. Maybe that's good enough
On Thu, 1 Jan 2004, Tom Lane wrote:
> "Marc G. Fournier" <[EMAIL PROTECTED]> writes:
> > I'm still loading the 'WITHOUT OIDS' database ... should I expect that,
> > with CLUSTERing, its performance would be slightly better yet, or would
> > the difference be negligible?
>
> I think the difference
"Marc G. Fournier" <[EMAIL PROTECTED]> writes:
> I'm still loading the 'WITHOUT OIDS' database ... should I expect that,
> with CLUSTERing, its performance would be slightly better yet, or would
> the difference be negligible?
I think the difference will be marginal, but worth doing; you're
reduci
On Thu, 1 Jan 2004, Tom Lane wrote:
> "Marc G. Fournier" <[EMAIL PROTECTED]> writes:
> > On Thu, 1 Jan 2004, Tom Lane wrote:
> >> "Marc G. Fournier" <[EMAIL PROTECTED]> writes:
> >>> what sort of impact does CLUSTER have on the system? For instance, an
> >>> index happens nightly, so I'm guessing
Tom Lane wrote:
Not sure that it's fair to characterize this as a property of the
relational model. It is a property of the SQL standard.
Yes indeed - I fell into the classic "Relational model and SQL are not
the same thing" trap !
Mark
---(end of broadcast)
On Thu, 1 Jan 2004, Bruce Momjian wrote:
> Marc G. Fournier wrote:
> > 186_archives=# \d ndict7
> > Table "public.ndict7"
> > Column | Type | Modifiers
> > -+-+
> > url_id | integer | not null default 0
> > word_id | integer | not null defau
Joseph Shraibman writes:
> Tom Lane wrote:
>> BTW, 7.4 also has a specialized index opclass that can be used to
>> create LIKE-compatible indexes even if you are using a non-C locale.
>>
> Where is that documented?
http://www.postgresql.org/docs/current/static/indexes-opclass.html
> Is it automat
Andreas writes:
> Since it is no official RPM anyway you could build it yourself as well
> if your server holds the necesary compilers and whatnot ...
> I stopped using SuSE's binaries for PG some time ago since they don't
> upgrade officially on newer versions and I'd rather have a "clean"
> insta
"Marc G. Fournier" <[EMAIL PROTECTED]> writes:
> 'k, and for todays question ... how does one 'knock up the stats target'?
ALTER TABLE [ ONLY ] name [ * ]
ALTER [ COLUMN ] column SET STATISTICS integer
The default is 10; try 100, or even 1000 (don't think it will let you
go higher than 1000).
On Thu, 1 Jan 2004, Tom Lane wrote:
> Mark Kirkwood <[EMAIL PROTECTED]> writes:
> > Might be worth trying a larger statistics target (say 100), in the hope
> > that the planner then has better information to work with.
>
> I concur with that suggestion. Looking at Marc's problem:
>
>
Mark Kirkwood <[EMAIL PROTECTED]> writes:
> Might be worth trying a larger statistics target (say 100), in the hope
> that the planner then has better information to work with.
I concur with that suggestion. Looking at Marc's problem:
Tino Wildenhain (Thursday 01 January 2004 11:33)
> > I'm just saying that it would be nice to include both CLI and GUI
> > interfaces, not to mention things like ODBC, as an alternative to the
> > "minimalist" download.
>
> No. NO! Definitively not. I really dont want GUI interfaces on a
> database
On Thu, 1 Jan 2004, Arjen van der Meijden wrote:
> Marc G. Fournier wrote:
> >
> > Now, if I knock off the LIKE, so that I'm returning all rows from ndict8,
> > join'd to all the URLs that contain them, you get:
>
> Can't you build seperate databases for each domain you want to index?
> Than you w
"Chris Ochs" <[EMAIL PROTECTED]> writes:
> Is this a crazy way to handle this?
Depends. Do you care if you lose that data (if the system crashes
before your daemon can insert it into the database)? I think the
majority of the win you are seeing comes from the fact that the data
doesn't actually
Hi Casey,
Casey Allen Shobe wrote:
Alex Satrapa (Sunday 28 December 2003 22:16)
Just convince your distribution's
My what? I don't use no stinkin' distribution :).
postgresql package maintainer
That would be postgresql.org, I know not of binary packages.
"suggests/recommends" portion of
"Matthew Nuzum" <[EMAIL PROTECTED]> writes:
> Thanks for the very quick reply... I didn't know about the dbsize stuff,
> they may help. Unfortunately, the records are mixed together.
When measuring the on-disk size of a table, don't forget to include its
indexes and its toast table (and the toast
On Thu, 2004-01-01 at 15:10, Stephane Pinel wrote:
> Happy new year to all pgsql fans !
>
> Sorry for this trivial question but I couldn't find an answer in the
> archives :
>
> I use SERIAL type in tables for id columns in order to auto increment
> them. Is there a way to get
> the last insert
You should use curval after inserting
and this can be done in one step
insert into foo (c1,c2,...) values ( v1, v2...); select curval( sequence
);
Dave
On Thu, 2004-01-01 at 10:10, Stephane Pinel wrote:
> Happy new year to all pgsql fans !
>
> Sorry for this trivial question but I couldn't find
If you use nextval before the insert, you should use the value in the insert
itself. Afterwards you can use currval to get the just inserted value.
I'm surprised you can't find this in the archives, it's asked on an almost
weekly basis.
It's also question 4.15.2 of the FAQ:
http://www.postgresql
On Thu, 1 Jan 2004, Stephane Pinel wrote:
> the last inserted id in the table like we do with MySQL using the
> GetLastInsertID ?
>
> My need is to get back the new id just after inserting.
Use currval() after you have inserted.
http://www.postgresql.org/docs/current/static/functions-sequence.
On Dec 31, 2003, at 7:20 PM, Chris Travers wrote:
This concept of using complex types in tables actually does have one
legitimate use. When used with casts and functions, you could use it
as a
"poor-man's datatype" development method.
Here is a hypothetical example. Imagine for a moment that
Happy new year to all pgsql fans !
Sorry for this trivial question but I couldn't find an answer in the
archives :
I use SERIAL type in tables for id columns in order to auto increment
them. Is there a way to get
the last inserted id in the table like we do with MySQL using the
GetLastInsertID
Let's say I am writing a file for creating a database. Say ...
-- schematest
CREATE SEQUENCE foo_id_seq;
CREATE TABLE foo(
id integer
PRIMARY KEY
DEFAULT nextval('foo_id_seq'),
xx text
);
I want to be able to ...
lee=# drop schema beta cascade;
DROP SCHEMA
lee=# create sch
Marc G. Fournier wrote:
Now, if I knock off the LIKE, so that I'm returning all rows from ndict8,
join'd to all the URLs that contain them, you get:
Can't you build seperate databases for each domain you want to index?
Than you wouldn't need the like operator at all.
The like-operator doesn't see
Hi Tom,
> Another possibility is that t_stockchanges has child table(s). Your
> SELECT would count rows in the child tables, but I don't think that
That's the case. I tried to copy the content of t_stockchanges table into a
temp table.
Being very lazy:) I created the temp table using create tabl
Might be worth trying a larger statistics target (say 100), in the hope
that the planner then has better information to work with.
best wishes
Mark
Marc G. Fournier wrote:
he problem is that right now, we look at the LIKE first, giving us ~300k
rows, and then search through those for those who
28 matches
Mail list logo
