> This can often be called for. I'm working on a 400GB data warehouse right
> now, and almost *all* of our queries run from materialized aggregate tables.
I thought that was pretty much the definition of data warehousing! :-)
--
Mike Nolan
---(end o
, which is about 4200 transactions/second.
--
Mike Nolan
---(end of broadcast)---
TIP 7: don't forget to increase your free space map settings
tement instead of COPY.
The hardware is a Dell dual Xeon system, the disks are mirrored SATA
drives with write buffering turned off.
--
Mike Nolan
---(end of broadcast)---
TIP 4: Don't 'kill -9' the postmaster
at match the structure of
the tables they are logging.
2. Write a trigger function that converts columns to something you can
store in a common log table. (I've not found a way to do this without
inserting one row for each column being logged, though.)
--
Mike Nolan
---
le-clicks even
when they only want one click.
--
Mike Nolan
---(end of broadcast)---
TIP 9: the planner will ignore your desire to choose an index scan if your
joining column's datatypes do not match
production server.
The same query a while later might respond quickly again.
I'm not sure where to look for the delay, either, and it is intermittent
enough that I'm not even sure what monitoring techniques to use.
--
Mike Nolan
---(end of broadcast)---
ammers working
on tuning issues for SQL Server than PostgreSQL has working on the
whole project.
--
Mike Nolan
---(end of broadcast)---
TIP 1: subscribe and unsubscribe commands go to [EMAIL PROTECTED]
> Mike Nolan wrote:
> > Is there a way to copy a table INCLUDING the check constraints? If not,
> > then that information is lost, unlike varchar(n).
>
> "pg_dump -t" should work fine, unless I'm misunderstanding you.
I was specifically referring to doing
> Actually, I don't. Good reason to have a check constraint on it though
> (hint, check constraints can be changed while column types cannot be, at
> this moment).
Is there a way to copy a table INCLUDING the check constraints? If not,
then that information is lost, unlike varch
rk as specified, I don't think
the standard cares much about what's happening behind the curtain.
--
Mike Nolan
---(end of broadcast)---
TIP 4: Don't 'kill -9' the postmaster
> Frankly, the only reason to use anything other than TEXT is compatibility with
> other databases and applications.
You don't consider a requirement that a field be no longer than a
certain length a reason not to use TEXT?
--
Mike Nolan
---(end o
when you've done your homework".
Can they call you at the unemployment office?
--
Mike Nolan
---(end of broadcast)---
TIP 3: if posting/reading through Usenet, please send an appropriate
subscribe-nomail command to [EMAIL PROTECTED] so
build indexes on a regular basis,
even if you move that field into a separate table.
--
Mike Nolan
---(end of broadcast)---
TIP 7: don't forget to increase your free space map settings
13 matches
Mail list logo
