as
bad or worse than the problem it's trying to solve.
Ok, but the danger is that the OOM killer kills your postmaster. To
me, this is a cure way worse than the disease it's trying to treat.
YMMD c. c.
A
--
Andrew Sullivan
[EMAIL PROTECTED]
+1 503 667 4564 x104
http://www.commandprompt.com
effects to your database. So for good
Postgres operation, you want to run on a machine with the OOM killer
disabled.
A
--
Andrew Sullivan
[EMAIL PROTECTED]
+1 503 667 4564 x104
http://www.commandprompt.com/
--
Sent via pgsql-performance mailing list (pgsql-performance@postgresql.org)
To make
vacuuming?
A
--
Andrew Sullivan
[EMAIL PROTECTED]
+1 503 667 4564 x104
http://www.commandprompt.com/
--
Sent via pgsql-performance mailing list (pgsql-performance@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-performance
, and is broken by applications doing DDL as part of the
regular operation.
A
--
Andrew Sullivan
[EMAIL PROTECTED]
+1 503 667 4564 x104
http://www.commandprompt.com/
--
Sent via pgsql-performance mailing list (pgsql-performance@postgresql.org)
To make changes to your subscription:
http
to send spam is hardly hacking the
list.)
A
--
Andrew Sullivan
[EMAIL PROTECTED]
+1 503 667 4564 x104
http://www.commandprompt.com/
--
Sent via pgsql-performance mailing list (pgsql-performance@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql
) for adaptively choosing different
update strategies that do not incur the full MVCC overhead?
How would you pick? But one thing you could do is create the table
with a non-standard fill factor, which might allow HOT to work its magic.
A
--
Andrew Sullivan
[EMAIL PROTECTED]
+1 503 667 4564
transactions no MVCC bloat seems to occur and updates are faster.
Are you on 8.3? That may be HOT working for you. MVCC doesn't get
turned off if there are no other transactions (it can't: what if
another transaction starts part way through yours?).
A
--
Andrew Sullivan
[EMAIL PROTECTED]
+1 503 667 4564
will work before you deploy to production. (The other way to
say that, of course, is Linux is only free if your time is worth
nothing. Substitute your favourite free software for Linux, of
course. ;-) )
A
--
Andrew Sullivan
[EMAIL PROTECTED]
+1 503 667 4564 x104
http://www.commandprompt.com
administrators, the accounting people
want to know why the free software costs so much.
If you depend on your systems, though, you should never deploy any
change, no matter how innocuous it seems, without testing.
I agree completely.
--
Andrew Sullivan
[EMAIL PROTECTED]
+1 503 667 4564 x104
http
your
application and your database, in my experience.
A
--
Andrew Sullivan
[EMAIL PROTECTED]
+1 503 667 4564 x104
http://www.commandprompt.com/
--
Sent via pgsql-performance mailing list (pgsql-performance@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref
to know about in the context (with
only 8Go of memory, I don't consider this a powerful box at all,
note). But why wouldn't it be on the same network? You're using the
network stack anyway, note: JVMs can't go over domain sockets.
A
--
Andrew Sullivan
[EMAIL PROTECTED]
+1 503 667 4564 x104
http
by the corresponding postgres server process for my
thread is
small it does not seem to be the bottleneck. There has to be a bottleneck
somewhere else.
Do you agree or is there some flaw in my reasoning?
- Original Message
From: Matthew Wakeling [EMAIL PROTECTED]
To: andrew klassen [EMAIL PROTECTED
PROTECTED]
To: pgsql-performance@postgresql.org
Sent: Wednesday, June 4, 2008 10:10:38 AM
Subject: Re: [PERFORM] insert/update tps slow with indices on table 1M rows
On Wed, 4 Jun 2008, andrew klassen wrote:
I am using multiple threads, but only one worker thread for insert/updated
involves file I/O) improve the
above scenario?
Thanks.
- Original Message
From: James Mansion [EMAIL PROTECTED]
To: andrew klassen [EMAIL PROTECTED]
Cc: pgsql-performance@postgresql.org
Sent: Wednesday, June 4, 2008 3:20:26 PM
Subject: Re: [PERFORM] insert/update tps slow with indices
Running postgres 8.2.5
I have a table that has 5 indices, no foreign keys or any
dependency on any other table. If delete the database and
start entering entries, everything works very well until I get
to some point (let's say 1M rows). Basically, I have a somewhat
constant rate of
length of two
text fields. There are 5 total indices: 1 8-byte, 2 4-byte and 2 text fields.
As mentioned all indices are btree.
- Original Message
From: PFC [EMAIL PROTECTED]
To: andrew klassen [EMAIL PROTECTED]; pgsql-performance@postgresql.org
Sent: Tuesday, June 3, 2008 7:15:10
On May 21, 2008, at 12:33 AM, Shane Ambler wrote:
Size can affect performance as much as anything else.
For a brief moment, I thought the mailing list had been spammed. ;-)
J. Andrew Rogers
--
Sent via pgsql-performance mailing list (pgsql-performance@postgresql.org)
To make changes
on that :).
I think you will find that no replication system will solve your
underlying problems. That said, I happen to work for a company that
will sell you a replication system to work with 8.1 if you really want
it.
A
--
Andrew Sullivan
[EMAIL PROTECTED]
+1 503 667 4564 x104
http
On Mon, Apr 28, 2008 at 07:48:48PM +0530, Gauri Kanekar wrote:
Slony don't do automatic failover. And we would appreciate a system with
automatic failover :(
No responsible asynchronous system will give you automatic failover.
You can lose data that way.
A
--
Andrew Sullivan
[EMAIL
On Wed, Apr 16, 2008 at 11:48:21PM +0200, Thomas Spreng wrote:
What I meant is if there are no INSERT's or UPDATE's going on it
shouldn't
affect SELECT queries, or am I wrong?
CHECKPOINTs also happen on a time basis. They should be short in that case,
but they still have to happen.
--
On Tue, Mar 11, 2008 at 02:19:09PM +, Matthew wrote:
of rows with IS NULL, then someone changes a row, then you find the count
of rows with IS NOT NULL. Add the two together, and there may be rows that
were counted twice, or not at all.
Only if you count in READ COMMITTED.
A
--
Sent
Miguel Arroz [EMAIL PROTECTED] wrote ..
I'm testing an update on 66k rows on Postgresql, and it seems
something is not right here.
My server is a Quad-Xeon 3.2 Ghz with 2 GB RAM and a RAID 1 running
FreeBSD 6.3 and PgSQL 8.3. My development machine is a PowerBook G4
1.67 Ghz with
route.
What I've done is remove the FK (maybe it would be better to leave it
albeit disabled for documentation) and written my own AFTER DELETE
trigger that uses EXECUTE to delay planning until the actual value is
known. This appears to work correctly.
--
Sincerely,
Andrew Lazarusmailto
I have a cascading delete trigger that is obviously using a seqscan.
(Explain analyze shows that trigger as taking over 1000s while all
other triggers are 1s. The value in test delete didn't even appear in
this child table, so an index scan would have been almost instant.)
If I do
DELETE FROM
On Tue, Feb 19, 2008 at 02:48:55PM +, Matthew wrote:
If there's not much write traffic, the WAL won't be used much anyway.
You still have checkpoints.
If you really don't care much about the integrity, then the best option is
probably to put the WAL on ramfs.
Um, that will cause the
and use a separate row for each
array index? The reason I didn't want to take this approach is because there
are
other columns in the row that will be duplicated needlessly.
Thanks, Andrew
Be a better
On Tue, Jan 29, 2008 at 04:28:45PM +0200, Adrian Moisey wrote:
Seriously though, how do I try measure this?
Is autovacuum not going to work for your case?
A
---(end of broadcast)---
TIP 9: In versions below 8.0, the planner will ignore your
On Fri, Jan 11, 2008 at 10:19:51AM -0500, Tom Lane wrote:
Given that the world is going to IPv6 in a few years whether you like it
or not, that seems pretty darn short-sighted to me.
Indeed. Even ARIN has finally started to tell people that IPv4 is running
out. There are currently significant
On Fri, Jan 11, 2008 at 05:02:36PM -0500, Michael Stone wrote:
networks), but there's a conspicuous lack of a type for (hosts). I
suppose if you really are sure that you want to store hosts and not
networks
Well, part of the trouble is that in the CIDR world, an IP without a netmask
can be
On Fri, Jan 11, 2008 at 02:38:27PM -0800, Steve Atkins wrote:
I don't think there's ambiguity about what an dotted-quad without a
netmask
means, and hasn't been for a long time. Am I missing something?
Well, maybe. The problem is actually that, without a netmask under CIDR,
the address
James DeMichele [EMAIL PROTECTED] wrote ..
Then, I have the following index on the table:
this_index (status, source_id, another_column)
If you have many queries of this type, do
CLUSTER this_index ON tablename;
and retry the SELECT.
MySQL is using some sort of auto-clustering ISAM on the
On Fri, Dec 21, 2007 at 12:09:28AM -0500, Merlin Moncure wrote:
Maybe a key management solution isn't required. If, instead of
strictly wrapping a language with an encryption layer, we provide
hooks (actors) that have the ability to operate on the function body
when it arrives and leaves
On Fri, Dec 21, 2007 at 12:40:05AM -0500, Tom Lane wrote:
whether there is a useful policy for it to implement. Andrew Sullivan
argued upthread that we cannot get anywhere with both keys and encrypted
function bodies stored in the same database (I hope that's an adequate
summary of his point
On Thu, Dec 20, 2007 at 03:35:42PM -0500, Merlin Moncure wrote:
Key management is an issue but easily solved. Uber simple solution is
to create a designated table holding the key(s) and use classic
permissions to guard it.
Any security expert worth the title would point and laugh at that
On Thu, Dec 20, 2007 at 01:45:08PM -0600, Roberts, Jon wrote:
Businesses use databases like crazy. Non-technical people write their own
code to analyze data. The stuff they write many times is as valuable as the
data itself and should be protected like the data. They don't need or want
many
On Thu, Dec 20, 2007 at 03:24:34PM -0600, Roberts, Jon wrote:
Actually, PostgreSQL already has column level security for pg_stat_activity.
Not exactly. pg_stat_activity is a view.
But I think someone suggested upthread experimenting with making pg_proc
into a view, and making the real
On Thu, Dec 20, 2007 at 05:04:33PM -0500, Merlin Moncure wrote:
right, right, thanks for the lecture. I am aware of various issues
with key management.
Sorry to come off that way. It wasn't my intention to lecture, but rather
to try to stop dead a cure that, in my opinion, is rather worse
I wrote
That's what I did at first, but later I found better performance with
a TRIGGER on the permanent table that deletes the target of an UPDATE,
if any, before the UPDATE. [INSERT!] That's what PG does anyway, and now I
can do
the entire UPDATE [INSERT] in one command.
It's probably
Adam PAPAI [EMAIL PROTECTED] wrote ..
Hi pgsql-performance,
I've a problem with the select * on a small table.
I can think of two possibilities for such incredibly slow performance.
One: your table has not been VACUUMed for a long time and is full of dead
tuples. Try VACUUM FULL on it, or
Loïc Marteau [EMAIL PROTECTED] wrote ..
Steve Crawford wrote:
If this
is correct, I'd first investigate simply loading the csv data into a
temporary table, creating appropriate indexes, and running a single
query to update your other table.
My experience is that this is MUCH faster. My
checkpoint, I'm seeing transactions running 2-3 seconds.
During this time, writes are 5/minute.
What gives?
pg_dump? Remember that it has special locks approximately equivalent
(actually eq? I forget) with SERIALIZABLE mode, which makes things rather
different.
A
--
Andrew Sullivan
Old sigs
?
Probably by buying much faster disk hardware. You'll note that the query
plans you posted are the same, except for the actual time it took to get the
results back. That tells me you have slow storage. On subsequent runs,
the data is cached, so it's fast.
A
--
Andrew Sullivan
Old sigs will return
everything you need.
But are you sure there are _no other_ transactions open when you do that?
This could cause problems, and CLUSTER's behaviour with other open
transactions is not, um, friendly prior to the current beta.
A
--
Andrew Sullivan
Old sigs will return after re-constitution of blue
to your user (or just connect as postgres
user) for the time being, while debugging this.
A
--
Andrew Sullivan
Old sigs will return after re-constitution of blue smoke
---(end of broadcast)---
TIP 6: explain analyze is your friend
On Wed, Nov 14, 2007 at 11:58:23AM -0500, Andrew Sullivan wrote:
No, every statement in psql is a transaction. Even SELECT. Every statement
Err, to be clearer, Every statement in psql is _somehow_ part of a
transaction; if you don't start one explicitly, the statement runs on its
own
that is doing something there (you won't see an UPDATE in
that case), or else something else is causing INSERTs to fail.
A
--
Andrew Sullivan
Old sigs will return after re-constitution of blue smoke
---(end of broadcast)---
TIP 4: Have you searched our
. That should cause errors that you'd get in the log, presuming that
you have the log level set correctly.
A
--
Andrew Sullivan
Old sigs will return after re-constitution of blue smoke
---(end of broadcast)---
TIP 1: if posting/reading through Usenet
is the only way -- if you insert directly, it will happily insert
into that column. But it should cause an error to show in the log, which is
what's puzzling me.
A
--
Andrew Sullivan
Old sigs will return after re-constitution of blue smoke
---(end of broadcast
as a constant or is that
also a parameter?
--
Andrew, Supernews
http://www.supernews.com - individual and corporate NNTP services
---(end of broadcast)---
TIP 9: In versions below 8.0, the planner will ignore your desire to
choose an index scan if your
numbers of failed vacuums,
however, I suspect your problem is I/O. Vacuum churns through the
disk very aggressively, and if you're close to your I/O limit, it can
push you over the top.
A
--
Andrew Sullivan | [EMAIL PROTECTED]
The year's penultimate month is not in truth a good way of saying
, at least to me, to be insurmountable.
Andrew
On 8/19/07, Niklas Saers [EMAIL PROTECTED] wrote:
Hi,
the company I'm doing work for is expecting a 20 times increase in
data and seeks a 10 times increase in performance. Having pushed our
database server to the limit daily for the past few months we
On 8/19/07, Luke Lonergan [EMAIL PROTECTED] wrote:
Andrew,
I'd say that commodity systems are the fastest with postgres - many have
seen big slowdowns with high end servers. 'Several orders of magnitude' is
not possible by just changing the HW,
Going from one or two SATA disks to a SAN
, so I can't really test these. I just saw the bigint
value as a default for an integer column and it caught my eye.
Hope this might help you avoid some problems when upgrading.
Andrew
---(end of broadcast)---
TIP 7: You can help support
Tilmann Singer [EMAIL PROTECTED] wrote ..
* Nis Jørgensen [EMAIL PROTECTED] [20070727 20:31]:
How does the obvious UNION query do - ie:
SELECT * FROM (
SELECT * FROM large_table lt
WHERE lt.user_id = 12345
UNION
SELECT * FROM large_table lt
WHERE user_id IN (SELECT
As other posters have pointed out, you can overcome the ORDER BY/LIMIT
restriction on UNIONs with parentheses. I think I misbalanced the parentheses
in my original post, which would have caused an error if you just copied and
pasted.
I don't think the limitation has to do with planning--just
valgog [EMAIL PROTECTED] wrote ..
On Jul 23, 7:00 pm, [EMAIL PROTECTED] (Tom Lane) wrote:
valgog [EMAIL PROTECTED] writes:
how to build an multicolumn index with one column order ASCENDING and
another column order DESCENDING?
Use 8.3 ;-)
In existing releases you could fake it with
and its hard- and
firm-ware, as well as its ability to interact with the OS. I think
the best answer is sometimes yes.
A
--
Andrew Sullivan | [EMAIL PROTECTED]
However important originality may be in some fields, restraint and
adherence to procedure emerge as the more significant virtues
\timing??? I don't get any time when using the
\timing option...
How so? It returns Time: N ms at the end of output for me.
A
--
Andrew Sullivan | [EMAIL PROTECTED]
In the future this spectacle of the middle classes shocking the avant-
garde will probably become the textbook definition
. Is there any rule of
thumb?
Actually I set it to +-256M.
There has been Much Discussion of this lately on this list. I
suggest you have a look through the recent archives on that topic.
A
--
Andrew Sullivan | [EMAIL PROTECTED]
The year's penultimate month is not in truth a good way of saying
for the EXPLAIN
ANALYSE to return, I assumed that the problem is one of impatience and
not clock cycles. After all, the gettimeofday() additional overhead
is still not going to come in on the order of minutes without a
_bursting_ huge query plan.
A
--
Andrew Sullivan | [EMAIL PROTECTED
you're going
to get your redundancy back is to go noticably slower :-(
will lose a very little bit in comparison. Andrew Sullivan had a
somewhat similar finding a few years ago on some old Solaris hardware
that unfortunately isn't at all relevant today. He basically found
that moving WAL off
an undemonstrated benefit and
probably a whole lot of new bugs?
A
--
Andrew Sullivan | [EMAIL PROTECTED]
In the future this spectacle of the middle classes shocking the avant-
garde will probably become the textbook definition of Postmodernism.
--Brad Holland
that 6 drives in
RAID5, even if they're 15,000 RPM. The rotation speed is the least
of your problems in many RAID implementations.
A
--
Andrew Sullivan | [EMAIL PROTECTED]
The year's penultimate month is not in truth a good way of saying
November.
--H.W. Fowler
to, but then the
INSERTing transaction rolls back, it leaves a dead tuple in its wake.
My guess, from your posted example, is that you have the latter case
happening, because you have removable rows (that's assuming you
aren't mistaken that there's never a delete or update to the table).
A
--
Andrew
was that, for high-contention workloads like the ones we
happened to be working on, an optimistic approach like Postgres-R is
probably always going to be a loser.
A
--
Andrew Sullivan | [EMAIL PROTECTED]
In the future this spectacle of the middle classes shocking the avant-
garde will probably become
-- like maybe in a loop
-- would be better for your case.
A
--
Andrew Sullivan | [EMAIL PROTECTED]
In the future this spectacle of the middle classes shocking the avant-
garde will probably become the textbook definition of Postmodernism.
--Brad Holland
more I/O, and actually more CPU wouldn't
hurt, because then you could run three VACUUMs on three separate
tables (on three separate disks, of course) and not have to switch
them off and on the CPU.
A
--
Andrew Sullivan | [EMAIL PROTECTED]
A certain description of men are for getting out of debt
at least limit it to one list?
A
--
Andrew Sullivan | [EMAIL PROTECTED]
Everything that happens in the world happens at some place.
--Jane Jacobs
---(end of broadcast)---
TIP 3: Have you checked our extensive FAQ?
http
it, and since we're not, we can't possibly know about it,
right ;-) But there are some materials about why to use Postgres on
the website:
http://www.postgresql.org/about/advantages
A
--
Andrew Sullivan | [EMAIL PROTECTED]
When my information changes, I alter my conclusions. What do you do sir
On Mon, Jun 18, 2007 at 02:38:32PM -0400, Andrew Sullivan wrote:
I've picked -advocacy.
Actually, I _had_ picked advocacy, but had an itchy trigger finger.
Apologies, all.
A
--
Andrew Sullivan | [EMAIL PROTECTED]
A certain description of men are for getting out of debt, yet are
against all
, that wasn't the case
for relatively small buffers; with the replacement of single-pass
LRU, that has certainly changed, but I'd be surprised if anyone
tested a buffer as large as 32G.
A
--
Andrew Sullivan | [EMAIL PROTECTED]
The whole tendency of modern prose is away from concreteness
an exclusive lock, but the basic conceptual
problem is the same.
A
--
Andrew Sullivan | [EMAIL PROTECTED]
Unfortunately reformatting the Internet is a little more painful
than reformatting your hard drive when it gets out of whack.
--Scott Morris
---(end
*after* it has completed and postgres has told
me so by logging a slow query entry in my logs?
You can't :(
A
--
Andrew Sullivan | [EMAIL PROTECTED]
This work was visionary and imaginative, and goes to show that visionary
and imaginative work need not end up well.
--Dennis
at is to
see whether you are in fact hitting 100% of your I/O capacity and, if
so, what your options are for getting more room there.
A
--
Andrew Sullivan | [EMAIL PROTECTED]
The year's penultimate month is not in truth a good way of saying
November.
--H.W. Fowler
segments (maybe
partitions, maybe something else) would help, so I know for sure that
someone is working on a problem like this, but I don't think it's the
sort of thing that's going to come any time soon.
A
--
Andrew Sullivan | [EMAIL PROTECTED]
I remember when computers were frustrating because
at it. But
it seems a waste to re-implement something that's already apparently
working for you in favour of something more expensive that you don't
seem to need.
A
--
Andrew Sullivan | [EMAIL PROTECTED]
When my information changes, I alter my conclusions. What do you do sir
that certainly had a similar issue, but I couldn't
show you the data to prove it. Everyone who used it knew about it,
though.
A
--
Andrew Sullivan | [EMAIL PROTECTED]
A certain description of men are for getting out of debt, yet are
against all taxes for raising money to pay it off
On Wed, Jun 06, 2007 at 09:20:54PM +0200, Gunther Mayer wrote:
What the heck could cause such erratic behaviour? I suspect some type of
resource problem but what and how could I dig deeper?
Is something (perhaps implicitly) locking the table? That will cause
this.
A
--
Andrew Sullivan
that _other_ transactions don't get I/O
starved. (Make vacuum fast isn't in most cases an interesting
goal.)
A
--
Andrew Sullivan | [EMAIL PROTECTED]
I remember when computers were frustrating because they *did* exactly what
you told them to. That actually seems sort of quaint now
, and so
doing things to improve the chances of correct storage is a good
idea.
A
--
Andrew Sullivan | [EMAIL PROTECTED]
Everything that happens in the world happens at some place.
--Jane Jacobs
---(end of broadcast)---
TIP 2
of queries
I bet that single disk is your problem. Iostat is your friend, I'd
say.
A
--
Andrew Sullivan | [EMAIL PROTECTED]
Everything that happens in the world happens at some place.
--Jane Jacobs
---(end of broadcast)---
TIP 1
that index and creating a new one on just backup_id. This
should be a net wash on space, and the new index should make for a
straight index scan for the query you presented. Don't forget to
analyze after changing the indexes.
Hope this helps.
Andrew
---(end of broadcast
scheduling safely, you have to be really
sure that you know what the other transactions are doing.
A
--
Andrew Sullivan | [EMAIL PROTECTED]
Information security isn't a technological problem. It's an economics
problem.
--Bruce Schneier
---(end of broadcast
they don't get in
the way, they do the right thing in the minimal case, and they give the
advanced user a lot more choices about multiple DB instances on the same
machine.
Cheers,
Andrew McMillan
Let me just thank the list, especially for the references. (I found
similar papers myself with Google: and to think I have a university
library alumni card and barely need it any more!)
I'll write again on the sorts of results I get.
BEGIN:VCARD
VERSION:2.1
N:Lazarus;Andrew;;;Ph.D.
FN:Andrew
?
Thanks.
Andrew Lazarus [EMAIL PROTECTED]
---(end of broadcast)---
TIP 3: Have you checked our extensive FAQ?
http://www.postgresql.org/docs/faq
killed
it, and I wasn't in retrospect sure an index that took something like
6GB by itself would be helpful on a 2GB of RAM box.
MK I don't think that will work for the vector norm i.e:
MK |x - y| = sqrt(sum over j ((x[j] - y[j])^2))
MK Cheers
MK Mark
--
Sincerely,
Andrew Lazarus
On 2007-04-15, Tom Lane [EMAIL PROTECTED] wrote:
Andrew - Supernews [EMAIL PROTECTED] writes:
Looking at current CVS code the RI check seems to be skipped on update of
the _referred to_ table if the old and new values match, but not on update
of the _referring_ table.
No, both sides
, but not on update
of the _referring_ table.
--
Andrew, Supernews
http://www.supernews.com - individual and corporate NNTP services
---(end of broadcast)---
TIP 2: Don't 'kill -9' the postmaster
. Have you done any benchmarks on 8.2.x that
show that you get an improvement from this, or did you just take the
too much of a good thing is wonderful approach?
Cheers,
Andrew.
-
Andrew
, and
see if there are any noticable changes in behaviour.
--
Andrew, Supernews
http://www.supernews.com - individual and corporate NNTP services
---(end of broadcast)---
TIP 9: In versions below 8.0, the planner will ignore your desire
by the OS). That's on
a 2.8GHz xeon.
--
Andrew, Supernews
http://www.supernews.com - individual and corporate NNTP services
---(end of broadcast)---
TIP 6: explain analyze is your friend
).
--
Andrew, Supernews
http://www.supernews.com - individual and corporate NNTP services
---(end of broadcast)---
TIP 2: Don't 'kill -9' the postmaster
How about this option:
SELECT distinct ip_info.* FROM ip_info RIGHT JOIN network_events USING
(ip) RIGHT JOIN host_events USING (ip) WHERE
(network_events.name='blah' OR host_events.name = 'blah') AND
ip_info.ip IS NOT NULL;
MA Nah, that seems to be much much worse. The other queries
into a 64bit PCI bus).
Andrew
---(end of broadcast)---
TIP 2: Don't 'kill -9' the postmaster
- Original Message -
From: Jim C. Nasby [EMAIL PROTECTED]
To: Bob Dusek [EMAIL PROTECTED]
Cc: pgsql-performance@postgresql.org
Sent: Wednesday, January 10, 2007 2:01 PM
Subject: Re: [PERFORM] performance implications of binary placement
Are you 100% certain that both builds are
For the reasons indicated (that is, MVCC), PG can not do a DISTINCT or the
equivalent
GROUP BY from index values alone.
If this table is large, perhaps you could denormalize and maintain a
summary table with date (using truncation) and count, updated with
triggers on the original table. This
On Sun, Nov 26, 2006 at 09:24:29AM -0500, Rod Taylor wrote:
attempt and fail a large number of insert transactions then you will
still need to vacuum.
And you still need to vacuum an insert-only table sometimes, because
of the system-wide vacuum requirement.
A
--
Andrew Sullivan | [EMAIL
I don't believe DROP is necessary; use TRUNCATE instead. No need to re-create
dependent objects.
Peter Childs [EMAIL PROTECTED] wrote ..
On 24/11/06, Arnau [EMAIL PROTECTED] wrote:
Hi all,
I have a table with statistics with more than 15 million rows. I'd
like to delete the oldest
restored, actually works.
A
--
Andrew Sullivan | [EMAIL PROTECTED]
Everything that happens in the world happens at some place.
--Jane Jacobs
---(end of broadcast)---
TIP 1: if posting/reading through Usenet, please send
101 - 200 of 401 matches
Mail list logo
