shouldn't ever block other transactions, and this approach
will definitely run that risk.
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 Fri, May 06, 2005 at 02:39:11PM -0700, Mischa Sandberg wrote:
> IBM, Sun and HP have their fairly pricey Opteron systems.
We've had some quite good experiences with the HP boxes. They're not
cheap, it's true, but boy are they sweet.
A
--
Andrew Sullivan | [EMAIL PROTEC
The systems are nevertheless performing very well --
we did a load test that was pretty impressive. Also, Chris Browne
pointed me to this for the drivers:
http://sourceforge.net/projects/cciss/
A
--
Andrew Sullivan | [EMAIL PROTECTED]
A certain description of men are for getting out of debt, ye
more work than
you need to. If your UPDATEs are chasing down a lot of dead tuples,
for instance, you'll peg your I/O even though you ought to have I/O
to burn.
A
--
Andrew Sullivan | [EMAIL PROTECTED]
The whole tendency of modern prose is away from concreteness.
--George
etail in what
> was done...
Yes, it shows the actual timings, and the actual number of rows. But
if the estimates that the planner makes are wildly different than the
actual results, then you know your statistics are wrong, and that the
planner is going about things the wrong way. ANALYSE is a bi
ris and Tom were telling me
about how to tune my database.
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
---
occasional REINDEX to
solve; I forget which version you said you were using).
The painful part about tuning a production system is really that you
have to keep about 50 variables juggling in your head, just so you
can uncover the one thing that you have to put your finger on to make
it all play
? If it's very large compared to the data you have stored in
there, you may want to ask if you're "leaking" space from the free
space map (because of that table turnover, which seems pretty
severe).
A
--
Andrew Sullivan | [EMAIL PROTECTED]
The whole tendency of modern
achine?). Is this a time, for
example, when logrotate is killing your I/O with file moves?
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.
--J.D. B
really wedded to this design? (I have a feeling that something along
the lines of what Tom Lane said would be a better answer -- I think
you need to be more clever, because I don't think this will ever work
well, on any system.)
A
--
Andrew Sullivan | [EMAIL PROTECTED]
This work was visionary an
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 Su
duling will really hurt.
This means that, to use CPU 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.
he
> minimum go to a RAID1). Workload will primarily be comprised 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.
On Fri, May 18, 2007 at 03:26:08PM -0700, Abu Mushayeed wrote:
> Also, this query ran today and it already finished. Today it was
> IO intensive.
Are you entirely sure that it's not a coincidence, and something
_else_ in the system is causing the CPU issues?
A
--
Andr
worth storing correctly, 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)
lity, introduced so 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. Th
read-only data 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 compu
row enough hardware money 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 con
er system
that I've used 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 al
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
nly get
> told about the slow query *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
-- first thing I'd look 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
ase works
differently, by taking 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
arge one? In the past, 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
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
, we'd be
violating 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 alte
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
aga
at problem. Another part of the
problem 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 sh
each table -- 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.
--B
ob. You probably need 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
y a working
low-level part of your design to get 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 Po
to get faster disk 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
Novem
r update to the table).
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 of broadcast)---
TIP 9:
ds on your SAN 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 mor
where the battery is. Even if it's slower (and I don't
know whether it will be), I assume that having the right data more
slowly is better than maybe not having the data at all, quickly.
A
--
Andrew Sullivan | [EMAIL PROTECTED]
The plural of anecdote is not data.
r?
> ...can I use \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 becom
size?
> On a dedicated postgres server with 4 Giga RAM. 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 PRO
on the order of hours 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 Sulliva
ur WAL is near to its I/O limits, the only way 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&#x
at due to large 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"
me EXPLAIN ANALYSE
queries to understand that.
A
--
Andrew Sullivan | [EMAIL PROTECTED]
The whole tendency of modern prose is away from concreteness.
--George Orwell
---(end of broadcast)---
TIP 2: Don't 'kill -9' the postmaster
iew of storage, not the point of view of
the user).
A
--
Andrew Sullivan | [EMAIL PROTECTED]
The plural of anecdote is not data.
--Roger Brinner
---(end of broadcast)---
TIP 6: explain analyze is your friend
ses to show that the
tiny loss of memory to FSM is worth (a) an exclusive lock and (b) the
loss of efficiency you get from having some preallocated pages in
tables.
A
--
Andrew Sullivan | [EMAIL PROTECTED]
The fact that technology doesn't work is no bar to success in the marketpla
may have
to fiddle with it from time to time.
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.
--J.D. Baldwin
---(end of bro
eally empty, the performance effect is positive. If you have VACUUM
FULLed table, inserts have to extend the table before inserting,
whereas in a table with some space reclaimed, the I/O effect of
having to allocate another disk page is already done.
A
--
Andrew Sullivan | [EMAIL PROTECT
't happen
at the same time, because the bits might move out from under the
SELECT while it's running. Concurrency is hard, and race conditions
are easy, to implement.
A
--
Andrew Sullivan | [EMAIL PROTECTED]
A certain description of men are for getting out of debt, yet are
against all t
rdware is fixed and cannot be
changed," is the first optimisation I'd make. Heck, I gave away a
box to charity only two weeks ago that would solve your problem
better than automatically issuing VACUUM FULL.
A
--
Andrew Sullivan | [EMAIL PROTECTED]
Information security isn't a technol
actly the right settings
for any generic workload yet under 8.1 (although probably people know
them well enough for particular workloads).
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.
On Tue, Jan 17, 2006 at 11:43:14AM -0500, Chris Browne wrote:
> [EMAIL PROTECTED] (Andrew Sullivan) writes:
> > Because nothing that runs automatically should ever take an exclusive
> > lock on the entire database,
> That's a bit more than what autovacuum would probabl
uot;standard" as of
> 8.0...
And it doesn't work very well without changes to buffering. You need
both pieces to get it to work.
A
--
Andrew Sullivan | [EMAIL PROTECTED]
In the future this spectacle of the middle classes shocking the avant-
garde will probably b
ot of time on trying to emulate
the new features in 7.4.
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
--
x27;t change _at all_? Are you
sure no VACUUMs or anything are happening automatically?
> Anyway, I take it that there is no way to bypass the optimizer and
> instruct PostgreSQL exactly how one wants the search performed?
No, there isn't.
A
--
Andrew Sullivan | [EMAIL PROTECTED]
pushing the processor up to 99.9% active).
Are there any locks preventing the query from completing? I can't
recall how you check in 7.3, but if nothing else, you can check with
ps for something WAITING.
A
--
Andrew Sullivan | [EMAIL PROTECTED]
Unfortunately reformatting the Internet
ate or nonexistent ANALYZE stats, missing
> custom adjustments of statistics target settings, etc.
But even the nested loop shouldn't be a "never returns" case, should
it? For 1800 rows?
(I've _had_ bad plans that picked nestloop, for sure, but they're
usually for tens
hinking about strategies and am still a bit lost. Our
> apps are up 24/7 and we didn't code for the eventuality of having the
> db going offline for maintenance... we live and learn!
You shouldn't need to, with anything after 7.4, if your vacuum
regimen is right. There's some
ptom," might be
helpful to users. Because the impatient simply won't wait for the
full report to come back, and therefore they'll end up flying blind
instead. (Note that "the impatient" is not always the person logged
in and executing the commands.)
A
--
Andrew Sulli
none".
(That said, I appreciate that there's precious little reason to spend
a lot of work optimising a feature that is mostly there to counteract
bad management practices.)
A
--
Andrew Sullivan | [EMAIL PROTECTED]
When my information changes, I alter my conclusions. What do you do
ss
frequently. That's a good thing just because ANALYSE will impose an
I/O load.
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.
--Alexander Hamilton
---
ting from it, but all your other transactions depend on knowing
the value of the "unprocessed queue", the design just doesn't work
under PostgreSQL. It turns out to be impossible to keep the table
vacuumed well enough for high performance.
A
--
Andrew Sullivan | [EMAIL PROTECTED]
queries
in question.
The next thing I'd look for is OS-level performance problems.
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.
the use-cases I hear
for a statement-level hints system fall into this latter category.
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.
--Sco
gs showing increased time too? Are your
targets getting further behind?
3. Your backups "from the slave" aren't done with pg_dump,
right?
But I suspect Slony has a role here, too. I'd look carefully at the
slony tables -- especially the sl_log and pg_listen things, which
way, don't use pg_dump on a replica. There's a tool that comes
with slony that will allow you to take consistent, restorable dumps
from replicas if you like. (And you might as well throw away the
dumpfiles from the replicas that you have. They won't work when you
restore them.)
A
7;t rely on a pg_dump of a replica giving you a dump that, when
restored, actually works.
A
--
Andrew Sullivan | [EMAIL PROTECTED]
Everything that happens in the world happens at some place.
--Jane Jacobs
---(end of broadcast)---
TIP
-performance charter now, so if
anyone wants to pursue this, I urge you to take it to the Slony
list.)
A
--
Andrew Sullivan | [EMAIL PROTECTED]
Windows is a platform without soap, where rats run around
in open sewers.
--Daniel Eran
---(end of broadcast)--
ave issues on your system tables. I'd
do a VACUUM FULL and a complete REINDEX of the system tables next.
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 quain
pursue it. I'm willing to put it up
on gborg, though, if anyone thinks it'll be worth having around.
FWIW, we use ours in production.
A
--
Andrew Sullivan | [EMAIL PROTECTED]
The plural of anecdote is not data.
--Roger Brinner
---(end of broa
mentioned why not have the entire DB in memory? How do I
> configure that, for knowledge?
You don't. It'll automatically be in memory if (a) you have enough
memory, (b) you don't have anything else on the machine using the
memory, and (c) it's been read
not swapping? Note that vmstat on multiprocessor Solaris
machines is not notoriously useful. You may want to have a look at
what the example stuff in the SE Toolkit tells you, or what you get
from sar. I believe you have to use a special kernel setting on
Solaris to mark shared memory as being i
oated pig compared to Linux, at least when it comes to
managing the largish number of processes that Postgres requires.
If pure speed is what you're after, I have found that 2-way, 32 bit
Linux on P-IIIs compares very favourably to 4 way 64 bit Ultra SPARC
IIs.
A
--
Andrew Sullivan | [EMAI
at
> last.
I seem to have hit a bad batch of Dell hardware recently, which makes
me second this opinion.
I should say, also, that my initial experience of AIX has been
extremely good. I can't comment on the fun it might involve in the
long haul, of course.
A
--
Andrew Sullivan | [
On Tue, Oct 05, 2004 at 09:47:36AM -0700, Josh Berkus wrote:
> As long as you're on x86, scaling outward is the way to go. If you want to
> continue to scale upwards, ask Andrew Sullivan about his experiences running
> PostgreSQL on big IBM boxes. But if you consider an quad-
imagine other MUAs have such a feature
too.
> Sure enough, quoting the constants fixes the problem.
>
> Is it a best practice to always quote constants?
No, but it's very useful in these cases. The problem is I believe
this is fixed in 8.0, BTW. See the FAQ, question 4.8
A
--
And
t clues, at least indirectly. I can't
imagine that there's going to be a lot of enthusiasm for hints, so
anything that isn't a sure-fire planner helper is a potential loss,
at least to me.
A
--
Andrew Sullivan | [EMAIL PROTECTED]
I remember when computers were frustrating bec
acks of
completely locking the DBA's knowledge out of the system.
A
--
Andrew Sullivan | [EMAIL PROTECTED]
The plural of anecdote is not data.
--Roger Brinner
---(end of broadcast)---
TIP 5: Have you checked our exte
t to a relatively low level. What that ought to mean
is that, under heavy load, some queries will abort.
A
--
Andrew Sullivan | [EMAIL PROTECTED]
When my information changes, I alter my conclusions. What do you do sir?
--attr. John Maynard Keynes
---(
all stay
cached. Also, VACUUM does nasty things to the cache. It is hoped
that nastiness is fixed in 8.0.
--
Andrew Sullivan | [EMAIL PROTECTED]
The plural of anecdote is not data.
--Roger Brinner
---(end of broadcast)---
TIP 8: explain analyze is your friend
f the cache. Also, we'd need some more
info about how you've tuned this thing. Maybe check out the archives
first for some tuning pointers to help you.
A
--
Andrew Sullivan | [EMAIL PROTECTED]
In the future this spectacle of the middle classes shocking the avant-
garde will probabl
On Wed, Nov 03, 2004 at 03:53:16PM -0500, Andrew Sullivan wrote:
> and may bust your query out of the cache. Also, we'd need some more
Uh, the data you're querying, of course. Queries themselves aren't
cached.
A
--
Andrew Sullivan | [EMAIL PROTECTED]
I remember w
se!" We told them to take a long walk off a
short pier. Their service people sure _try_ hard in the field, but
some machines required three and four visits to fix.
I also find the Sun Opteron offering to be way overpriced compared to
the competition.
In case it's not obvious, I don&#
y moveing the WAL into the array.
We've had some remarkably good experiences with our recently-acquired
EMC.
A
--
Andrew Sullivan | [EMAIL PROTECTED]
When my information changes, I alter my conclusions. What do you do sir?
--attr. John Maynard Keynes
--
r to the original
question, Afilias does indeed use PostgreSQL for this, and is happy
to talk on the record about it.
A
--
Andrew Sullivan | [EMAIL PROTECTED]
The fact that technology doesn't work is no bar to success in the marketplace.
--Philip Greenspun
> improved in performance nearly as quickly as CPUs have.
Indeed. And you can go through an awful lot of budget buying solid
state storage ;-)
A
--
Andrew Sullivan | [EMAIL PROTECTED]
I remember when computers were frustrating because they *did* exactly what
you told them to. That actually see
On Wed, Jan 19, 2005 at 10:42:26AM -0500, Alan Stange wrote:
>
> I'm fairly sure that the pi and po numbers include file IO in Solaris,
> because of the unified VM and file systems.
That's correct.
A
--
Andrew Sullivan | [EMAIL PROTECTED]
When my information changes, I a
M P690 or a big Sun
(I'd counsel against that, though) or something like that? Or even
some Opterons. Dual Xeon is probablt your very worst choice at the
moment.
A
--
Andrew Sullivan | [EMAIL PROTECTED]
Information security isn't a technological problem. It's
On Thu, Jan 20, 2005 at 10:40:02PM -0200, Bruno Almeida do Lago wrote:
>
> I was thinking the same! I'd like to know how other databases such as Oracle
> do it.
You mean "how Oracle does it". They're the only ones in the market
that really have this techno
the database ...
You could use SSD for your storage. That'd make it go rather quickly
even if it had to seek on disk.
A
--
Andrew Sullivan | [EMAIL PROTECTED]
The plural of anecdote is not data.
--Roger Brinner
---(end of broadcast)
e to be snarky, but the reason there isn't this kind of system
just hanging around is that it's a Very Hard Problem. I spent 2 days
last week in a room with some of the smartest people I know, and
there was widespread agreement that what you want is a very tough
problem.
A
--
A
moment dumping from a
slave gives you a useless database dump.
A
--
Andrew Sullivan | [EMAIL PROTECTED]
The fact that technology doesn't work is no bar to success in the marketplace.
--Philip Greenspun
---(end of broadcast)--
more connections, by the way, I can tell you
that Solaris 8, in my experience, is _very bad_ at managing context
switches. So you may not be merely I/O bound (although your other
reports seem to indicate that you are).
A
--
Andrew Sullivan | [EMAIL PROTECTED]
The whole t
ot -- in some cases it'll modify kernel parameters behind the
scenes. In my case, I didn't have superuser access, so there wasn't
a danger; but I've heard sysadmins complain about this.
A
--
Andrew Sullivan | [EMAIL PROTECTED]
This work was visionary an
andling such cases is a little painful. (We didn't give
up on Solaris because of cs problems, BTW; but I have to say that AIX
seems to be a little less prone to self-DOS on this front than
Solaris was. If you really want to hear me rant, ask me some time
about ecache and Sun support.)
On Sat, Nov 10, 2007 at 09:22:58PM -0500, Jean-David Beyer wrote:
> >
> > So, there are NO failed inserts, and no updates? Cause that's what
> > I'd expect to create the dead rows.
> >
> So would I. Hence the original question.
Foreign keys with cascadi
rows, something is producing them. Either INSERT is
firing a trigger 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
onflict with used sequence
values. 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)---
TI
ting a
> primary key, so it should be impossible anyhow.
I thought you were doing INSERTs? It's not true that the output of the
sequence 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'
STER will do 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-con
l do it
You could grant superuser status 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
> run too?
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 Sulliva
1 - 100 of 219 matches
Mail list logo
