Hello,
I have two "large" tables - "sessions" (about 1.500.000 rows) and
"actions" (about 4.000.000 rows), and the "actions" table is connected
to the "sessions" (it contains a key from it). The simplified structure
of these tables is
sessions (
session_id int4,
visitor_id int4,
Hi, Lucas,
[EMAIL PROTECTED] schrieb:
> Is there a way to construct a multi schema in my data base?
> Something like:
> mysystem.finances.money.tables
> mysystem.finances.money.functions
> mysystem.finances.credits.tables
> mysystem.finances.credits.functions
> mysystem.amount.products
On Mar 3, 2005, at 6:05 AM, Dracula 007 wrote:
Hello,
I have two "large" tables - "sessions" (about 1.500.000 rows) and
"actions" (about 4.000.000 rows), and the "actions" table is connected
to the "sessions" (it contains a key from it). The simplified structure
of these tables is
sessions (
On Mar 2, 2005, at 7:15 PM, Casey T. Deccio wrote:
A database I am currently using is built and updated periodically from
a
flat csv file (The situation is rather unfortunate, but that's all I
have right now). The schema I use is more complex than the flat file,
so I follow a process to populate
On Mar 3, 2005, at 8:34 AM, Dracula 007 wrote:
It looks like you are going to always do a sequential scan on the
tables, as you always look a the entire table(s). How often do you
do the query as compared to the load on the database? If you do the
query often relative to the load, could you k
Could you set up functions triggers on the temp table that would do updates
and inserts on the other tables from the data entered into the temp table?
Then all you would have to do is inter the data into the temp table
-Original Message-
From: Casey T. Deccio [mailto:[EMAIL PROTECTED]
Se
There is no difference in run-time between a VIEW
and executing the underlying SELECT because it's the same.
You may move your question to the [PERFORMANCE] list
for hints to speed up your query.
Regards, Christoph
Steffen Boehme wrote:
>
> Hello there,
>
> i have a short question ...
>
Hi, Casey,
Casey T. Deccio schrieb:
> There is more than one problem with this, but the largest is that I
> would like to perform this whole database rebuild within one
> transaction, so other processes that need to access the database can do
> so without noticing the disturbance. However, perfo
[EMAIL PROTECTED] (PFC) writes:
>> The reason PostgreSQL is slower is because it (and by extension the team
>> behind it) cares about your data.
>
> Sure, postgres is (a bit but not much) slower for a simple
> query like SELECT * FROM one table WHERE id=some number, and
> postgres is a lot sl
On Thu, 2005-03-03 at 06:23 -0700, Sean Davis wrote:
> Why not rebuild the entire thing in a separate "build" schema then do
> only the stuff like copying tables inside the transaction block:
>
Building everything in the separate "build" schema works great, but it
is the DELETE (TRUNCATE won't wo
On Thu, 2005-03-03 at 08:28 -0700, Markus Schaber wrote:
> - Create the new date in another schema, and then simply rename those
> two schemas for "switch over"
>
This worked very well. I created another schema ("build") and populated
the tables within build. Then:
BEGIN;
ALTER SCHEMA public R
Hi, Casey,
Casey T. Deccio schrieb:
> Question: is there an "easy" way to duplicate an existing schema
> (tables, functions, sequences, etc.)--not the data; only the schema?
> This way, I would only need to modify one schema (public) to make
> changes, and the build schema could be created each t
Casey T. Deccio wrote:
Question: is there an "easy" way to duplicate an existing schema
(tables, functions, sequences, etc.)--not the data; only the schema?
This way, I would only need to modify one schema (public) to make
changes, and the build schema could be created each time as a duplicate
of t
On Mar 3, 2005, at 1:37 PM, Casey T. Deccio wrote:
On Thu, 2005-03-03 at 08:28 -0700, Markus Schaber wrote:
- Create the new date in another schema, and then simply rename those
two schemas for "switch over"
This worked very well. I created another schema ("build") and
populated
the tables within
Hi, Casey,
Casey T. Deccio schrieb:
> Building everything in the separate "build" schema works great, but it
> is the DELETE (TRUNCATE won't work when foreign keys point to the table)
Just as an additional info: You could temporarily drop the foreing key
constraints, run TRUNCATE, and recreate t
On 2005-03-03, Bret Hughes <[EMAIL PROTECTED]> wrote:
> a RFE would be to let to_timestamp be to a timezone without time zone
> and have a to_timestamptz do the time zone thing. Seems more consistent
> and would give me the functionality I am looking for :)
Unix epoch times correspond to timestam
On Thu, 2005-03-03 at 14:58, Andrew - Supernews wrote:
> On 2005-03-03, Bret Hughes <[EMAIL PROTECTED]> wrote:
> > a RFE would be to let to_timestamp be to a timezone without time zone
> > and have a to_timestamptz do the time zone thing. Seems more consistent
> > and would give me the functionali
On 2005-03-04, Bret Hughes <[EMAIL PROTECTED]> wrote:
>> Unix epoch times correspond to timestamp _with_ time zone.
>>
>> (Why are you using timestamp without time zone anyway? For recording the
>> time at which an event occurred that usage is simply wrong - in fact I
>> can't see any situation in
On Mar 4, 2005, at 14:47, Bret Hughes wrote:
On Thu, 2005-03-03 at 14:58, Andrew - Supernews wrote:
(Why are you using timestamp without time zone anyway? For recording
the
time at which an event occurred that usage is simply wrong - in fact I
can't see any situation in which a Unix epoch time ca
19 matches
Mail list logo
