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 ineffi
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 the
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
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
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 devel
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 all
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 re
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 m
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 optimize
"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 exten
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
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
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 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 .
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.
A
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 and
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 base
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 broadcast)-
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.
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 us
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
21 matches
Mail list logo
