How will that work when people reside at
123A Some St.
Address that need to be sorted and/or grouped in any way should be
stored as multiple fields.
door number
door number suffix Most often a letter
street name prefix Section
street name
street name suffix Direcetion
I agree, NS or EW long lat should be the same.
I was just pointing to the wrong figure. Also, if ll_to_earth takes lat
first, it should report an error for a |lat| 90...
Michael Fuhr wrote:
On Sat, Oct 02, 2004 at 09:29:16PM -0400, Jean-Luc Lachance wrote:
Maybe it would work with the right
Maybe it would work with the right long lat...
try
Protland OR -122.67555, 45.51184
Seattle WA -122.32956, 47.60342
Also, do not forget that it is the line distance not the driving distance.
Michael Fuhr wrote:
On Sat, Oct 02, 2004 at 07:09:25PM -0400, Tom Lane wrote:
mike cox [EMAIL PROTECTED]
Use a SERIAL id on messages, then
Select * from messages
where id = int8( random() * currval({sequence_name}));
Arnau Rebassa wrote:
Hi everybody,
I'm doing the following query:
select * from messages order by random() limit 1;
in the table messages I have more than 200 messages and a lot of
Add :
AND count(user_tasks.task_id) 0 in the where clause.
Greg Donald wrote:
Converting some MySQL code to work with Postgres here.
I have this query:
SELECT
tasks.task_id,
(tasks.task_duration * tasks.task_duration_type /
count(user_tasks.task_id)) as hours_allocated
FROM tasks
LEFT JOIN
Try:
insert into pending_tnmt_sec
select tseceventid, tsecsecno,
nextval('sec_seq'),
tsecrtddt
from (
select tseceventid, tsecsecno, tsecrtddt
from tnmtsec
order by tsecrtddt,tseceventid,tsecsecno) as ss;
Mike Nolan wrote:
I have the following insert to populate a new table:
insert into
http://developer.postgresql.org
Bruce Momjian wrote:
David Parker wrote:
Is there a spec/posting somewhere that more or less reflects how
tablespaces are supposed to work in 7.5? I've found a lot of info on it
by searching the archives, but I haven't found the posting that
describes the basic
Lee,
Have a look at this simpler non looping version of week_start()
-- return the first date in the given week
CREATE or REPLACE FUNCTION week_start(integer, integer)
RETURNS date
LANGUAGE 'plpgsql'
AS '
DECLARE
pyear ALIAS FOR $1;
pweek ALIAS FOR $2;
year_start date;
week_interval
BULL.
How many times does PG have to scan the whole table because of MVCC?
At least with partitioning there is a fighting chance that that won't be
necessary.
Queries that involve the field on which the table is partitioned execute
faster by an order of magnitude.
It also helps with vaccuming as
Jean-Luc Lachance wrote:
BULL.
How many times does PG have to scan the whole table because of MVCC?
At least with partitioning there is a fighting chance that that won't be
necessary.
Queries that involve the field on which the table is partitioned execute
faster by an order of magnitude
or whatever and the commited tuples deleted (all this with
appropriate locks).
I am not sure if there is a need for the update count.
JLL
Christopher Browne wrote:
In the last exciting episode, [EMAIL PROTECTED] (Jean-Luc Lachance) wrote:
How about keeping counts of inserts, deletes and updates
How about keeping counts of inserts, deletes and updates per table per
transaction as part of the live statistics?
Tom Lane wrote:
I said:
Greg Stark [EMAIL PROTECTED] writes:
Things like count(*) could use int4 until it overflows though.
I don't see a reasonable way for an aggregate
I second that.
I have discussed adding partitioning tables almost a year ago...
No need to partition a functional index or anything like that.
Just partition on a specific field.
Ron Johnson wrote:
[...]
Partitioning should be put on the TODO list soon after tablespaces
(or DBA-defined
OUCH!!! Do a COUNT(*) on a 10M row table Forget it.
Here is a simple solution.
Add a SERIAL field to the table.
Set the maximum value for that sequence to the number of records you
want to keep.
Use a before insert trigger to replace the insert with an update if the
key already exist.
No
Shouldn't dates be validated using the *LOCALE setting and not try to
guess?
Tom Lane wrote:
Frank Miles [EMAIL PROTECTED] writes:
If the application always passes the date to Postgres with the three-letter
month name where appropriate, and use the 4-digit year, it should be
15 matches
Mail list logo
