What do you need to do more of, inserts or updates? If the answer is
updates, just do an update and then check for the number of rows affected.
If it is 0, follow it with an insert, if not, you are done.
You could do this in a stored procedure to save you the round trip of data
between the DB and
> I'm confused, where was the sarcasm?
Sarcasm: "A form of wit that is marked by the use of sarcastic language
and is intended to make its victim the butt of contempt or ridicule."
The banks, an corporations that act just like them, being the "victim",
obviously...
Bas.
-
> brought to my attention is that PHP is natively supported by Apache
> and JSP requires a separate interpreter (Jakarta or whatever).
There is more to life than Apache and there are much better Java solutions
than Jakarta! If you want to go the Java way, do yourself a favour and use
http://www.ori
I've done this, it is easy. Well, in the UK anyway. We have something
called the national grid (http://www.gps.gov.uk/natgrid/introduction.asp)
But it should be fairly easy to convert long/lat to a simpler grid for
your country.
If you haven't read the intro to thr grid, it is basicaly a 0 point
s
Just use the CASE statment, example:
create table test (foo int, bar int);
insert into test2 values (1, 2);
insert into test2 values (4, 3);
select case when foo > bar then foo else bar end from test2;
Bas.
---(end of broadcast)---
TIP 3: if posti
Klint,
> select groname from pg_group
> where (select usesyside from pg_shadow where usename = 'postgres') =
> any(grolist);
Unless you are lgged in as superuser (and applications other than pgAdmin
et al shouldn't be) you will get access denied on pg_shadow. (because it
contains passwords) Select
If the user/groups you are talking about are postgres users and groups,
this is it:
select * from pg_catalog.pg_group where (select usesysid from
pg_catalog.pg_user where usename = 'user') = any(grolist)
The place to find this kind of thing is the Postgres Internals section
(system catalogs) that
scott.marlowe said:
> Yes. drop cpu_tuple_index_cost by a factor of 100 or so
No effect.
> Also up effective_cache_size. It's measured in 8k blocks, so for a
That's better, set to 9000, which seems reasonable for my current setup,
it will start using the index when RANDOM_PAGE_COST <= 1.5.
> No
Hi Scot,
scott.marlowe said:
> So, to start with, try changing random page cost. you can change it for
As "unrealistic" as it should be, I need <1 before Postgres takes the
bait. Initialy 0.7, to be exact, but later It also worked at a little
higher setting of 1. I have given PG 96Mb of memory to
