The docs are correct so my initial point was correct. "position('ch' in
user) = 0" is equivalent to "user NOT LIKE '%ch%'" and there's no way
you can index that.
Well = 1 then.
Chris
---(end of broadcast)---
TIP 1: if posting/reading through U
Greg Stark wrote:
> I'm sure this isn't the only possible gotcha but I do seem to recall
> that on Solaris there's no such thing as a default LD_LIBRARY_PATH.
> Every binary stores absolute paths to every shared library it's
> linked against.
On Solaris you can actually use relative library paths
Thomas Hallgren wrote:
Tom Lane wrote:
Tim Allen <[EMAIL PROTECTED]> writes:
Thomas Hallgren wrote:
The position function must look for 'ch' everywhere in the string so
there's no way it can use an index.
I think the '= 0' bit is what Chris was suggesting could be the basis
f
Yeah. AFAICS the transformation Chris suggested is valid. I'm really
dubious that it's worth expending planner cycles to look for it though.
LIKE is something that everybody and his brother uses, but who uses this
position()=0 locution?
One of our junior developers :) Which is why I noticed i
Tom Lane wrote:
Tim Allen <[EMAIL PROTECTED]> writes:
Thomas Hallgren wrote:
The position function must look for 'ch' everywhere in the string so
there's no way it can use an index.
I think the '= 0' bit is what Chris was suggesting could be the basis
for an optimisation.
Tim Allen <[EMAIL PROTECTED]> writes:
> Thomas Hallgren wrote:
>> The position function must look for 'ch' everywhere in the string so
>> there's no way it can use an index.
> I think the '= 0' bit is what Chris was suggesting could be the basis
> for an optimisation.
Yeah. AFAICS the transfor
Thomas Hallgren wrote:
Christopher Kings-Lynne wrote:
Is it worth allowing this:
select count(*) from users_users where position('ch' in username) = 0;
To be able to use an index, like:
select count(*) from users_users where username like 'ch%';
At the moment the position() syntax will do a
Christopher Kings-Lynne wrote:
Is it worth allowing this:
select count(*) from users_users where position('ch' in username) = 0;
To be able to use an index, like:
select count(*) from users_users where username like 'ch%';
At the moment the position() syntax will do a seqscan, but the like
s
Is it worth allowing this:
select count(*) from users_users where position('ch' in username) = 0;
To be able to use an index, like:
select count(*) from users_users where username like 'ch%';
At the moment the position() syntax will do a seqscan, but the like
syntax will use an index.
Chris
[I thought this had gone out to the list when I first sent it, but now I
see that it didn't]
Actually, I've already looked at it very closely (spent a whole day
browsing the latest source code, in fact). The problem is csup still
doesn't support mirroring of the repository ",v" files. It only acts
On Thu, 2006-03-23 at 16:41 -0800, Joshua D. Drake wrote:
> Now it gives a error that type double does not exist.
> >>> CREATE DOMAIN double AS float8;
> >>>
> >>> There, now the type exists ;)
> >> That's a little too perl for me ;)
> >
> > I suppose it depends on the goal. If it is an appli
What is the virtue of this in any case? I can see considerable use for a
statically linked pg_dump, to help with upgrading, but not too much for
statically linked anything else, especially since we are now pretty
relocatable on most platforms at least.
Upgraded db server to 8.1, but don't want
On Thu, Mar 23, 2006 at 01:32:34PM -0800, Joel Miller wrote:
> Hello,
>
> I've been trying to get a local mirror of the cvs repository, but my
> connection attempts using rsync to cvsup.postgresql.org are always
> refused when I try to actually retrieve the pgsql-cvs collection. I tried
> to use r
On Mar 23, 2006, at 12:15 AM, Tom Lane wrote:
OK ... it's supposed to work to shift the whole installation tree to
a new root, ie, paths to places like the /share and /lib directories
are determined relative to where the backend executable actually is.
If this is not working on Solaris then for
Now it gives a error that type double does not exist.
CREATE DOMAIN double AS float8;
There, now the type exists ;)
That's a little too perl for me ;)
I suppose it depends on the goal. If it is an application that is to be
supported on more than one database, defining types and other things
Yes, that's one way to solve the problem. I was just trying to suggest
something that would benefit everyone in general while not opening up a
can of worms with regard to increased server load in the long term.
Joel
On Fri, Mar 24, 2006 at 4:34 PM, Kurt Roeckx ([EMAIL PROTECTED]) wrote:
>On Thu
Plain old cvs doesn't work for me because I need to get the repository,
not just a checkout of the sources, so I can do diffs, browse old
versions and what-not. I find that it's easier to understand code that's
been around for a while if I can observe how it's changed over time.
Usually, when I ha
On Thu, 2006-03-23 at 16:05 -0800, Joshua D. Drake wrote:
> Rod Taylor wrote:
> > On Thu, 2006-03-23 at 17:31 -0600, Tony Caduto wrote:
> >> I could have swore that this worked in earlier releases of Postgresql
> >> i.e. 7.4.
> >>
> >> CREATE TABLE public.test
> >> (
> >> junk double NOT NULL,
> >
It's only partially compatible: Like I mentioned earlier, csup currently
only acts as an alternative cvs checkout client.
Joel
On Thu, Mar 23, 2006 at 3:15 PM, Tom Lane ([EMAIL PROTECTED]) wrote:
>Is csup protocol-compatible with cvsup? If so people could use it
>without Marc having to do anyt
Rod Taylor wrote:
On Thu, 2006-03-23 at 17:31 -0600, Tony Caduto wrote:
I could have swore that this worked in earlier releases of Postgresql
i.e. 7.4.
CREATE TABLE public.test
(
junk double NOT NULL,
CONSTRAINT junk_pkey PRIMARY KEY (junk)
)WITHOUT OIDS;
Now it gives a error that type double
Which is actually a float8 :)
CREATE TABLE public.test
(
junk double precision,
);
alter table public.test add column foo float8;
Table "public.test"
Column | Type |
+--+--
junk | double precision |
punk | double precision |
Regards,
Guido Baro
Peter Eisentraut wrote:
There has never been a type named double in PostgreSQL. The type name
mandated by the SQL standard is double precision, and PostgreSQL
supports that.
Ok, Thanks for clearing that up for me :-)
Maybe it was pgAdmin that did the substitution.
Thanks,
Tony
--
Tom Lane wrote:
Martijn van Oosterhout writes:
Any particular reason why straight CVS doesn't work for you? Are you
that interested in having the log comment locally?
Personally, I'd really like to have a local repository copy, because
I spend a *lot* of time with cvsweb etc --- but
Tony Caduto wrote:
> I could have swore that this worked in earlier releases of Postgresql
> i.e. 7.4.
>
> CREATE TABLE public.test
> (
> junk double NOT NULL,
> CONSTRAINT junk_pkey PRIMARY KEY (junk)
> )WITHOUT OIDS;
There has never been a type named double in PostgreSQL. The type name
mandate
Tony Caduto <[EMAIL PROTECTED]> writes:
> I could have swore that this worked in earlier releases of Postgresql
> i.e. 7.4.
> CREATE TABLE public.test
> (
> junk double NOT NULL,
> CONSTRAINT junk_pkey PRIMARY KEY (junk)
> )WITHOUT OIDS;
> Now it gives a error that type double does not exist.
[
On Thu, 2006-03-23 at 17:31 -0600, Tony Caduto wrote:
> I could have swore that this worked in earlier releases of Postgresql
> i.e. 7.4.
>
> CREATE TABLE public.test
> (
> junk double NOT NULL,
> CONSTRAINT junk_pkey PRIMARY KEY (junk)
> )WITHOUT OIDS;
>
> Now it gives a error that type double
Tony Caduto wrote:
I could have swore that this worked in earlier releases of Postgresql
i.e. 7.4.
CREATE TABLE public.test
(
junk double NOT NULL,
CONSTRAINT junk_pkey PRIMARY KEY (junk)
)WITHOUT OIDS;
Now it gives a error that type double does not exist.
From the docs:
http://www.postgres
I could have swore that this worked in earlier releases of Postgresql
i.e. 7.4.
CREATE TABLE public.test
(
junk double NOT NULL,
CONSTRAINT junk_pkey PRIMARY KEY (junk)
)WITHOUT OIDS;
Now it gives a error that type double does not exist.
During the summer of 2004 I ported a large Firebird data
Martijn van Oosterhout writes:
> Any particular reason why straight CVS doesn't work for you? Are you
> that interested in having the log comment locally?
Personally, I'd really like to have a local repository copy, because
I spend a *lot* of time with cvsweb etc --- but I'm sure my needs are
sev
Alvaro Herrera wrote:
> Satoshi Nagayasu wrote:
>
>>Jim C. Nasby wrote:
>>
>>>Structure for the human-consumable output or for something that would be
>>>machine-parsed? ISTM it would be best to keep the current output as-is,
>>>and provide some other means for producing machine-friendly output,
>
Satoshi Nagayasu wrote:
> Jim C. Nasby wrote:
> > Structure for the human-consumable output or for something that would be
> > machine-parsed? ISTM it would be best to keep the current output as-is,
> > and provide some other means for producing machine-friendly output,
> > presumably in a table fo
Jim C. Nasby wrote:
> Structure for the human-consumable output or for something that would be
> machine-parsed? ISTM it would be best to keep the current output as-is,
> and provide some other means for producing machine-friendly output,
> presumably in a table format.
How about (well-formed) XML
Trying to work in the new role features into the information schema, I
noticed that there might be a few incompatibilities between the
implementation and what the SQL standard would like to see.
The way I understand this is that, according to the SQL standard, there
should be a current user and
On Thu, Mar 23, 2006 at 01:32:34PM -0800, Joel Miller wrote:
> Hello,
>
> I've been trying to get a local mirror of the cvs repository, but my
> connection attempts using rsync to cvsup.postgresql.org are always
> refused when I try to actually retrieve the pgsql-cvs collection. I tried
> to use r
Joel Miller wrote:
> Hello,
>
> I've been trying to get a local mirror of the cvs repository, but my
> connection attempts using rsync to cvsup.postgresql.org are always
> refused when I try to actually retrieve the pgsql-cvs collection. I
> tried to use rsync because cvsup is simply not an option
Hello,
I've been trying to get a local mirror of the cvs repository, but my
connection attempts using rsync to cvsup.postgresql.org are always
refused when I try to actually retrieve the pgsql-cvs collection. I tried
to use rsync because cvsup is simply not an option for me.
I'd like to suggest t
Christopher Kings-Lynne wrote:
To the GP, adding -lncurses (or rather the static equivalent) to your
link line should solve it. But if you include any other libraries like
ssl or kerberos be prepared to add a lot more.
With -lncurses or -lcurses I still can't get this to work. I add it
to t
"Kevin Grittner" <[EMAIL PROTECTED]> writes:
> I've never used gprof before, and from a quick scan of the info, it
> appears that I need to compile and link a special version of the
> software to generate the file that gprof needs. Is this correct? Does
> it work on a Windows build, or will I nee
On Thu, Mar 23, 2006 at 10:31:24AM +0800, Christopher Kings-Lynne wrote:
> >To the GP, adding -lncurses (or rather the static equivalent) to your
> >link line should solve it. But if you include any other libraries like
> >ssl or kerberos be prepared to add a lot more.
>
> With -lncurses or -lcurs
On Thu, Mar 23, 2006 at 12:29:27PM -0600, Kevin Grittner wrote:
> > Works out to about 30 microsec per node execution, which seems a
> > bit high for modern machines ... and the coarse quantization of the
> > CURRENT_TIMESTAMP results is odd too. What platform is this on
> > exactly?
>
> This is
>>> On Thu, Mar 23, 2006 at 11:27 am, in message
<[EMAIL PROTECTED]>,
Tom Lane <[EMAIL PROTECTED]> wrote:
> Profiling with gprof or some such tool might be educational.
I've never used gprof before, and from a quick scan of the info, it
appears that I need to compile and link a special version of
>>> On Thu, Mar 23, 2006 at 11:27 am, in message
<[EMAIL PROTECTED]>,
Tom Lane <[EMAIL PROTECTED]> wrote:
>> The run time of the NOT IN query, as measured by elapsed time
between
>> SELECT CURRENT_TIMESTAMP executions, increased by 31 ms.
>
> Works out to about 30 microsec per node execution, whi
To the GP, adding -lncurses (or rather the static equivalent) to your
link line should solve it. But if you include any other libraries like
ssl or kerberos be prepared to add a lot more.
With -lncurses or -lcurses I still can't get this to work. I add it to
the ${CC} line, right?
Chris
--
Tom Lane wrote:
Given the thought that we need both
transactional and nontransactional state for a sequence, I'm kind of
inclined to leave the transactional data in pg_class. We could still
imagine putting the nontransactional state into a new pg_sequence
catalog indexed by, say, the pg_class O
"Zeugswetter Andreas DCP SD" <[EMAIL PROTECTED]> writes:
> Of course if we still need one row in pg_class for the ACL's, that row
> might as well be a view.
Yeah, view or view-like thingie. Given the thought that we need both
transactional and nontransactional state for a sequence, I'm kind of
in
> Plan C would be to say that we don't need to preserve "SELECT * FROM
> seqname", but I'll bet there would be some hollering.
I'd like to hear this hollering first, before we create tons of views
:-)
Imho it is not a problem to remove it, I am for Plan C.
(Those with need for the select can stil
"Kevin Grittner" <[EMAIL PROTECTED]> writes:
> Tom Lane <[EMAIL PROTECTED]> wrote:
>> You didn't show us the explain analyze results,
> The below is cut & paste directly from a psql run without editing.
OK, so the two plans do indeed have much different node execution
counts. The EXPLAIN ANALYZ
On Thu, Mar 23, 2006 at 12:39:52AM -0500, Tom Lane wrote:
> "Akshat Nair" <[EMAIL PROTECTED]> writes:
> > Can I get the grammar for the explain output?
>
> There isn't one, it's just text and subject to change at a moment's
> notice :-(. The past proposals that we format it a bit more rigidly
> h
On Wed, Mar 22, 2006 at 09:43:24PM -0500, Bruce Momjian wrote:
> I am heading on vacation starting tomorrow/Thursday, and return the
> following Thursday, March 30th. I will be in Florida with my family.
Speaking of trips, I'm currently in Brussels, and will be here until
next Wednesday. Anyone w
On Thu, Mar 23, 2006 at 12:10:54AM +0200, Hannu Krosing wrote:
> ??hel kenal p??eval, K, 2006-03-22 kell 16:11, kirjutas Tom Lane:
> > Peter Eisentraut <[EMAIL PROTECTED]> writes:
> > > How does one get at the missing fields. The only way I know is
> > > selecting from the sequence, but how does
>>> On Wed, Mar 22, 2006 at 8:59 pm, in message
<[EMAIL PROTECTED]>,
Tom Lane <[EMAIL PROTECTED]> wrote:
> "Kevin Grittner" <[EMAIL PROTECTED]> writes:
> You didn't show us the explain analyze results,
The below is cut & paste directly from a psql run without editing.
bigbird=> UPDATE "User" S
Ühel kenal päeval, K, 2006-03-22 kell 21:50, kirjutas Andrew Dunstan:
> Tom Lane said:
> > Darcy Buskermolen <[EMAIL PROTECTED]> writes:
> >> On Wednesday 22 March 2006 13:11, Tom Lane wrote:
> >>> (Thinks a bit...) Maybe it would work for pg_sequence to be a real
> >>> catalog with a row per sequ
52 matches
Mail list logo
