On Sat, 3 Nov 2007, Ted Byers wrote:
As one of these programmers, where is the best place to find the
information I need to get it right...I ask you where I can learn what
you believe a good DBA needs to know.
What a DBA should know in general is a little different from the question
I think
Should an index be used on a created_at timestamp column if you know you
will be using ORDER BY created_at ASC|DESC from time to time?
Yes.
Thanks. This is stated explicitly in 8.3 docs (as opposed to 8.2)
http://www.postgresql.org/docs/8.3/static/indexes-ordering.html
And you should use
On Sun, 4 Nov 2007, Kevin Hunter wrote:
Am I assuming too much already by not defining what a DBA is in general?
Probably. I'd startby looking at the list of DBA duties at
http://en.wikipedia.org/wiki/Database_administrator and considering which
of those are database-specific for a second.
Hi all.
I'd like to know whether the indexes on a table are updated or not during
a COPY ... FROM request.
That is, should I drop all indexes during a COPY ... FROM in order to gain
the maximum speed to load data?
Thanks.
--
Reg me Please
---(end of
El dom, 04-11-2007 a las 02:16 +0100, Rainer Bauer escribió:
Abandoned wrote:
I tryed pg_dump but it is very slowly. Are there any faster way to
copy database?
Actually, I was looking for something along the same line.
I often want to test some functionality in my program based on the
The bigger danger is hiring an *Oracle* Financials or *Oracle* Manufacturing
person to become a DBA because they have 'Oracle'
on their resume
This is the most comprehensive analysis of DBA requirements I have seen thus
far
For myself I'm not tied to any specific Database having worked in mySQL
On 11/4/07, Reg Me Please [EMAIL PROTECTED] wrote:
Hi all.
I'd like to know whether the indexes on a table are updated or not during
a COPY ... FROM request.
That is, should I drop all indexes during a COPY ... FROM in order to gain
the maximum speed to load data?
Thanks.
Although
Il Sunday 04 November 2007 14:59:10 Josh Tolley ha scritto:
On 11/4/07, Reg Me Please [EMAIL PROTECTED] wrote:
Hi all.
I'd like to know whether the indexes on a table are updated or not during
a COPY ... FROM request.
That is, should I drop all indexes during a COPY ... FROM in order
On Nov 4, 2007, at 9:15 AM, Reg Me Please wrote:
Il Sunday 04 November 2007 14:59:10 Josh Tolley ha scritto:
On 11/4/07, Reg Me Please [EMAIL PROTECTED] wrote:
Hi all.
I'd like to know whether the indexes on a table are updated or
not during
a COPY ... FROM request.
That is, should I
Il Sunday 04 November 2007 16:21:41 Erik Jones ha scritto:
On Nov 4, 2007, at 9:15 AM, Reg Me Please wrote:
Il Sunday 04 November 2007 14:59:10 Josh Tolley ha scritto:
On 11/4/07, Reg Me Please [EMAIL PROTECTED] wrote:
Hi all.
I'd like to know whether the indexes on a table are updated
rihad [EMAIL PROTECTED] writes:
You mean Postgres wouldn't *always* use created_at's index with such
access patterns on a big table (even if one exists):
select * from foo order by created_at desc;
No, it wouldn't necessarily, and that's a good thing. A full-table
indexscan can often be
Josh Tolley [EMAIL PROTECTED] writes:
Although questions of which is faster often depend very heavily on
the data involved, the database schema, the hardware, etc., typically
people find it best to drop all indexes during a large import and
recreate them afterward.
See also the extensive
Hi,
Le Sunday 04 November 2007 11:22:19 Reg Me Please, vous avez écrit :
That is, should I drop all indexes during a COPY ... FROM in order to
gain the maximum speed to load data?
When looking for a way to speed up data loading, you may want to consider
pgbulkload, a project which optimizes
Alvaro Herrera [EMAIL PROTECTED] writes:
No, it isn't. Please add a TODO item about it:
* Prevent long-lived temp tables from causing frozen-Xid advancement
starvation
Jeff Amiel wrote:
Can somebody explain this one to me? because of our auditing technique, we
have many LONG lived temp
Ok, I committed the worst mistake in db admin. I upgraded to 8.1 on my debian
server but forgot to backup one of the databases. The 7.1 directory is still
there. I would like a list of options. I am not sure that temporarily
reinstalling 7.1 will allow access immediately or must I have to
On 04/11/2007 20:52, Jesus Arocho wrote:
Ok, I committed the worst mistake in db admin. I upgraded to 8.1 on my debian
server but forgot to backup one of the databases. The 7.1 directory is still
there. I would like a list of options. I am not sure that temporarily
reinstalling 7.1 will
On 11/4/07, Kevin Hunter [EMAIL PROTECTED] wrote:
Following up on a recent thread
(http://archives.postgresql.org/pgsql-general/2007-11/msg00064.php) ...
Next question and one that I'm not sure how to phrase: how does one
become a Postgres-savvy* DBA? Just by working with it as a developer
Dimitri, thank you for your quoting. I'm a pg_bulkload author.
pg_bulkload is optimized especially for appending data to table with indexes.
If you use it, you don't need to drop index before loading data. But you have to
consider conditions carefully as Dimitri said below. See also pg_bulkload
Merlin Moncure wrote:
On 11/4/07, Kevin Hunter [EMAIL PROTECTED] wrote:
Following up on a recent thread
(http://archives.postgresql.org/pgsql-general/2007-11/msg00064.php) ...
Next question and one that I'm not sure how to phrase: how does one
become a Postgres-savvy* DBA? Just by working
Hi,
A few days ago an insertion operation issued by a JDBC client that was
blocked by
postgreSQL. I could verify that by issuing the operation using psql. My
question is,
what could be causing this? There were other JDBC clients but they never
lock any
tables. They all used transactions with
You mean Postgres wouldn't *always* use created_at's index with such
access patterns on a big table (even if one exists):
select * from foo order by created_at desc;
No, it wouldn't necessarily, and that's a good thing. A full-table
indexscan can often be slower than a sort because of
21 matches
Mail list logo
