g about the spec which
makes it impossible.
A
--
Andrew Sullivan 204-4141 Yonge Street
Afilias CanadaToronto, Ontario Canada
<[EMAIL PROTECTED]> M2P 2A8
+1
nce. For what
it's worth, I can't see how this is something special about Postgres:
even raw-filesystem type systems have to make sure the disk actually
has the data, and a write cache is bound to be a big help for that.
A
--
Andrew Sullivan 204-414
On Fri, Oct 03, 2003 at 02:24:42PM -0600, Rob Nagler wrote:
> I've read some posts that says vacuum doesn't lock, but my experience
> today indicates the opposite. It seemed that "vacuum full analyze"
VACUUM doesn't. VACUUM FULL does.
--
Andrew Sullivan
On Fri, Oct 03, 2003 at 11:49:03PM -0400, Tom Lane wrote:
>
> What if said SELECTs are using the index in question?
That's a good reason to build a new index and, when it's done, drop
the old one. It still prevents writes, of course.
A
--
Andrew Sullivan
acuum is not free. It's _way_
cheaper than it used to be, though.
A
--
Andrew Sullivan 204-4141 Yonge Street
Afilias CanadaToronto, Ontario Canada
<[EMAIL PROTECTED]> M2P 2A8
r database, unless your database is
small. So you'll end up expiring potentially useful data in the
buffer.
A
--
Andrew Sullivan 204-4141 Yonge Street
Afilias CanadaToronto, Ontario Canada
<[EMAIL PROTECTED]>
the postmaster, but I
haven't the foggiest idea how to give it such intelligence.
A
--
Andrew Sullivan 204-4141 Yonge Street
Afilias CanadaToronto, Ontario Canada
<[EMAIL PROTECTED]> M2P 2A8
this problem. I certainly notice that performance gets
geometrically worse when you add a few hundred extra connections.
A
--
Andrew Sullivan 204-4141 Yonge Street
Afilias CanadaToronto, Ontario Canada
<[EMAIL PROTECTED]>
ns (and we always have more than 5
connections). It might be worth trying again, though, since we moved
to Sol 8.
Thanks for the result.
--
Andrew Sullivan 204-4141 Yonge Street
Afilias CanadaToronto, Ontario Canada
<[EMAIL PROTECTED]>
you'd better do. Combined with the new
probe-to-set-shared-buffers bit at install time, I think the reports
of 400 billion times worse performance than MySQL will probably
diminish.
A
--
Andrew Sullivan 204-4141 Yonge Street
Afilias CanadaTor
is for now? I agree with the
concern. I'd rather have slow'n'stable than fast-but-broken.
A
--
Andrew Sullivan 204-4141 Yonge Street
Afilias CanadaToronto, Ontario Canada
<[EMAIL PROTECTED]>
nything beyond -O2 just didn't work for gcc at the time.
A
--
Andrew Sullivan 204-4141 Yonge Street
Afilias CanadaToronto, Ontario Canada
<[EMAIL PROTECTED]> M2P 2A8
On Fri, Oct 10, 2003 at 09:01:12PM -0500, Ron Johnson wrote:
>
> > Does PostgreSQL only pick one index per table on the select statements?
>
> That's it's preference.
As far as I know, that's all it can do. Do you know something
different
in
pg_stat_activity, assuming you've turned on query echoing.
A
--
Andrew Sullivan 204-4141 Yonge Street
Afilias CanadaToronto, Ontario Canada
<[EMAIL PROTECTED]> M2P 2A8
g was seamless. I expect something similar is at work here.
Not that I've had a reason to play with 4G ix86 machines, anyway.
A
--
Andrew Sullivan 204-4141 Yonge Street
Afilias CanadaToronto, Ontario Canada
<[EMAIL PROTECTED]>
alls apart, and lots of people now have machines
well within that threshold. Heck, I'll bet Bruce's 2-way machine is
within that threshold.
A
--
Andrew Sullivan 204-4141 Yonge Street
Afilias CanadaToronto, Ontario Canada
<[EMAIL PROT
depend pretty heavily on what you're trying to
optimise for and what platform you have. But I'm glad to hear
(again) that people seem to think the 25% too high for most cases. I
don't feel so much like I'm tilting against windmills.
A
--
Andrew Sullivan
fill, even plain SELECTs
started taking a long time. The buffer algorithm is just not that
clever, was my conclusion.
(Standard disclaimer: not a long, controlled test. It's just a bit
of gossip.)
A
--
Andrew Sullivan 204-4141 Yonge Street
Afilias Canada
On Wed, Oct 22, 2003 at 09:27:47PM -0400, Tom Lane wrote:
> trace. What is causing that? Not VACUUM I don't think. It doesn't have
> any huge memory demand. But swapping out processes could account for
What about if you've set vacuum_mem too high?
A
--
was trying to ask. I didn't know if the memory was
actually taken by vacuum at the beginning (like shared memory is) or
what-all happened.
A
--
Andrew Sullivan 204-4141 Yonge Street
Afilias CanadaToronto, Ontar
turning it off?
A
--
Andrew Sullivan 204-4141 Yonge Street
Afilias CanadaToronto, Ontario Canada
<[EMAIL PROTECTED]> M2P 2A8
+1 416 646 3304 x110
-
On Fri, Oct 31, 2003 at 10:42:06AM -0600, Rob Sell wrote:
> For the record I am running on SuSE with a pretty much stock kernel. Not to
> sound na?ve, but is turning of HT something done in the bios?
As far as I know, yes.
A
--
Andrew Sullivan 204-4141 Yonge
On Wed, Nov 05, 2003 at 11:35:22AM -0600, [EMAIL PROTECTED] wrote:
> The \timing psql command gives different time for the same query executed
> repeatedly.
Why do you believe that the same query will always take the same time
to execute?
A
--
Andrew Sullivan
6
transaction_date | 0 | 8 | -0.200791 |0.289248
Any ideas? I'm loathe to recommend cluster, since the data will not
stay clustered.
A
--
Andrew Sullivan 204-4141 Yonge Street
Afilias CanadaToronto, Ontari
disks on a PCI controller
in this case. That does the trick, though, so maybe I'm just being
too conservantive.
A
--
Andrew Sullivan 204-4141 Yonge Street
Afilias CanadaToronto, Ontario Canada
<[EMAIL PROTECTED]>
On Thu, Nov 13, 2003 at 04:37:03PM -0500, Andrew Sullivan wrote:
> Actually, this one's on an internal box, and I think 1.5 is too low
> -- it's really just a pair of mirrored SCSI disks on a PCI controller
> in this case. That does the trick, though, so maybe I'm just b
udge on top of another kludge, perhaps? ;-) This
needs to be fixed properly, not through an ungraceful series of
workarounds.
A
--
Andrew Sullivan 204-4141 Yonge Street
Afilias CanadaToronto, Ontario Canada
<[EMAIL PROTECTED]>
claims disk space, i.e. it compacts the data
files and returns that space to the operating system.
A
--
Andrew Sullivan 204-4141 Yonge Street
Afilias CanadaToronto, Ontario Canada
<[EMAIL PROTECTED]>
use temp
tables a lot, you need to be sure to vacuum at least pg_class and
pg_attribute more frequently than you might have thought.
A
--
Andrew Sullivan 204-4141 Yonge Street
Afilias CanadaToronto, Ontario Canada
<[EMAIL PROTECTED]>
free to point me to any FAQ or previous message that already
> answers this question. Thanks in advance!
This is a pretty common sort of problem. See the archives of this
list for several fairly recent discussions of these sorts of
problems.
A
--
Andrew Sullivan
_ actually
scribed in the little bitty magnetic patterns -- and at that very
moment, the power goes away -- the data that was reported to have been
on the disk, but which was actually _not_ on the disk, is no longer
anywhere. (Well, except in the past. But time travel was disabled
some versions
ing too much on the filesystem buffers under certain perverse
loads is lousy database performance _precisely_ when we need it. I
expect some testing of this type some time in January.
A
--
Andrew Sullivan 204-4141 Yonge Street
Afilias CanadaToro
aviour, on the principle of "better
safe than sorry."
A
--
Andrew Sullivan 204-4141 Yonge Street
Afilias CanadaToronto, Ontario Canada
<[EMAIL PROTECTED]> M2P 2A8
uggestions?
----
Andrew Rawnsley
President
The Ravensfield Digital Resource Group, Ltd.
(740) 587-0114
www.ravensfield.com
---(end of broadcast)---
TIP 2: you can get off all lists at once with the unregister command
(send &
Low (1000). I'll fiddle with that. I just noticed that the machine only
has 512MB of ram in it, and not 1GB. I must
have raided it for some other machine...
On Jan 11, 2004, at 10:50 PM, Dennis Bjorklund wrote:
On Sun, 11 Jan 2004, Andrew Rawnsley wrote:
20-25% of the time. Fiddling
middle of the afternoon I would have no problems at all.
On Jan 12, 2004, at 12:40 AM, Tom Lane wrote:
Andrew Rawnsley <[EMAIL PROTECTED]> writes:
I have a situation that is giving me small fits, and would like to see
if anyone can shed any light on it.
In general, pulling 10% of a table *shou
rn large datasets it can potentially make things
worse (depending on implementation) through double-handling of the data.
As others have said too: 100 is just a configuration setting in
postgresql.conf - not an implemented limit.
Cheers,
On Fri, Jan 23, 2004 at 08:51:03AM -0800, Joshua D. Drake wrote:
>
>
> XFS.. hands down.
I thought it was you who recently said you thought there was some
sort of possible caching problem there?
A
--
Andrew Sullivan | [EMAIL PROTECTED]
The plural of anecdote is
g practically every binary setuid root gave
me fits. But XFS was nice.
--
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
---
e I'd be about
the degree of "testing" the filesystem has received on Linux. On the
other hand, I wouldn't be surprised if it were no worse than the
other options.
A
--
Andrew Sullivan | [EMAIL PROTECTED]
The fact that technology doesn't work is no
nefficient either
when using the cache or when doing cache maintenance.
A
--
Andrew Sullivan
---(end of broadcast)---
TIP 2: you can get off all lists at once with the unregister command
(send "unregister YourEmailAddressHere" to [EMAIL PROTECTED])
check up?
What's running on the machine during those hours? Maybe VACUUM is
sucking up all your bandwidth. Or your backups. Or some other
cron job.
Note that 7.2 is pretty old. There are several performance
improvements in subsequent versions.
A
--
Andrew Sullivan
-
All three tables have the same integer key,
and it's indexed.
I parenthesized the joins to do the two
small tables first.
I'm running and INSERT INTO ... SELECT
query with this join (one record added per record in join), 4 hours down and all
I have to show for it is 100 recycled transact
On Thu, Feb 26, 2004 at 12:46:23PM +, teknokrat wrote:
> I've read about the place. Would using -O3 be an improvement?
In my experience, it's not only not an improvement, it sometimes
breaks the code. That's on 8, though, not 9.
A
--
Andrew Sullivan | [EMAIL PROTEC
having 64 bits at your disposal.
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)---
TIP 2: you can get off
o provide some details of this? It sure sounds like a bug to
me, if it's true. I've never run into anything like this, though.
A
--
Andrew Sullivan | [EMAIL PROTECTED]
In the future this spectacle of the middle classes shocking the avant-
garde will probably become the textbook def
has had the best
Postgres minds work on it, and so far nobody's come up with a
solution. There was a proposal to put in a special-case automatic
fix for int4/int8 in 7.4, but I don't know whether it made it in.
A
--
Andrew Sullivan | [EMAIL PROTECTED]
I remember when computers were f
On Mon, Mar 08, 2004 at 11:22:56AM -0500, Neil Conway wrote:
> Actually, this has already been fixed in CVS HEAD (as I mentioned in
> this thread yesterday). To wit:
Yes, I saw that after I sent my mail. What can I say except, "Yay!
Good work!"
A
--
Andrew Sullivan | [EMAIL
efault on Solaris now. Again,
this is on 8, not 9.
At work, we have been doing a number of tests on 7.4. The
performance is such an improvement over 7.2 that the QA folks thought
there must be something wrong. So I suppose the defaults are ok.
A
--
Andrew Sullivan | [EMAIL
On Wed, Mar 10, 2004 at 11:07:28AM -0500, Andrew Sullivan wrote:
> At work, we have been doing a number of tests on 7.4. The
> performance is such an improvement over 7.2 that the QA folks thought
> there must be something wrong. So I suppose the defaults are ok.
I know, I know, re
create indexes with match my order by
fields perfectly; which is exactly what I am doing right now. But I
thought that maybe it might be worth while considering looking at allowing
some sort of in memory sort to be overlaid on an index if the statistics
indicate that the sorts are very nearly ordered.
Andrew
igh enough I kept a close eye on it (well, nagios did
anway.)
It depends on the workload. Your 16M setting would make many of my
clients' systems slow to an absolute crawl for some queries, and they
don't run into swap issues, because we've made educated guesses about
u
V8, which is not yet ready for prime time, maps many common Postgres
types into native JS types without the use of Input/Output functions,
which means the conversion is very fast. It's work which could very
well do with repeating for the other PL's.
cheers
andrew
--
Sent v
be hard to say much without a self-contained example
to try.
He's using EXECUTE ... USING. Does that plan with the used parameter?
cheers
andrew
--
Sent via pgsql-performance mailing list (pgsql-performance@postgresql.org)
To make changes to your subscription:
ing records older than, say, 90 days, 60 days, 30 days.
cheers
andrew
--
Sent via pgsql-performance mailing list (pgsql-performance@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-performance
is proposed
strategy. Or he could have tables partitioned by time and do the delete
by just dropping partitions. There are numerous way he could get this to
work.
cheers
andrew
--
Sent via pgsql-performance mailing list (pgsql-performance@postgresql.org)
To make changes to your subscrip
tens if not hundreds of Mb for any significantly sized database.
cheers
andrew
--
Sent via pgsql-performance mailing list (pgsql-performance@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-performance
hence I
*know* that 50G theoretical maximum will not be reached.
Can the OP say that? I have no reason to think so. Hence I don't
suggest 100M is OK on a 4G system.
Well, obviously you need to know your workload. Nobody said otherwise.
cheers
andrew
--
Sent via pgsql-performance mailing li
tter, but that will change in the future.
If all the rows have that value, then using the index would be silly.
Postgres knows from the stats that ANALYZE calculates whether or not
using an index is likely to be more efficient, and avoids doing so in
cases where it isn't.
cheers
and
, if you're not using that already. It's not as efficient as
COPY, but it's often a much less extensive change to the code.
cheers
andrew
--
Sent via pgsql-performance mailing list (pgsql-performance@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org
the value if you were to have the tablespaces on
different raid arrays. But what about on the same one?
Not answering your question, but standard advice is not to use RAID 5 or
6, but RAID 10 for databases. Not sure if that still hold if you're
using SSDs.
cheers
andrew
--
Sent via
On 04/01/2012 06:01 PM, Andy wrote:
You could try using Unix domain socket and see if the performance
improves. A relevant link:
He said Windows. There are no Unix domain sockets on Windows. (And
please don't top-post)
cheers
andrew
--
Sent via pgsql-performance mailing list (
On 04/01/2012 08:29 PM, Claudio Freire wrote:
On Sun, Apr 1, 2012 at 8:54 PM, Andrew Dunstan wrote:
You could try using Unix domain socket and see if the performance
improves. A relevant link:
He said Windows. There are no Unix domain sockets on Windows. (And please
don't top
On 04/01/2012 09:11 PM, Andrew Dunstan wrote:
On 04/01/2012 08:29 PM, Claudio Freire wrote:
On Sun, Apr 1, 2012 at 8:54 PM, Andrew Dunstan
wrote:
You could try using Unix domain socket and see if the performance
improves. A relevant link:
He said Windows. There are no Unix domain
plans
and times of queries nested in functions which can't easily be got
otherwise.
cheers
andrew
--
Sent via pgsql-performance mailing list (pgsql-performance@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-performance
whatever is in the from
clause to the table being updated. You almost never need it repeated in
the from clause.
cheers
andrew
--
Sent via pgsql-performance mailing list (pgsql-performance@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-performance
should show us
your memory settings, among other things - especially shared_buffers,
temp_buffers and work_mem.
cheers
andrew
--
Sent via pgsql-performance mailing list (pgsql-performance@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-performance
ta is perfectly ordered
in each table; on a less contrived example, it could well be a lot
slower.
It's not so terribly contrived, is it? It's common enough to have tables
which are append-only and to join them by something that corresponds to
the append order (serial field, timesta
0 loops=1)'
' Index Cond: ((activequeueid = 123456::numeric) AND (vstatus = 1) AND
(ventrydate > 0))'
'Total runtime: 0.076 ms'
This is the definition of the index :
CREATE INDEX i08_a_activity
ON a_activity
USING btree
(activequeueid , vstatus , ventrydate );
a_activity table has 1,216,134 rows
Thanks in advance,
Andrew
the default_statistics_target is set to 200, and I have run the analyze and
reindex on these tables before writing the email.
Andrew
> Date: Tue, 5 Jun 2012 08:15:45 -0500
> From: stho...@optionshouse.com
> To: andrewjai...@hotmail.com
> CC: pgsql-performance@postgresql.org
&
, even if it only wants one page right now.
cheers
andrew
--
Sent via pgsql-performance mailing list (pgsql-performance@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-performance
method of test db setup.
cheers
andrew
--
Sent via pgsql-performance mailing list (pgsql-performance@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-performance
makes a
difference. If it does you might want to look into using pg_reorg
periodically.
cheers
andrew
--
Sent via pgsql-performance mailing list (pgsql-performance@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-performance
On 07/19/2012 11:13 AM, Felix Scheicher wrote:
Andrew Dunstan dunslane.net> writes:
Try running CLUSTER on the relevant tables and see if it makes a
difference. If it does you might want to look into using pg_reorg
periodically.
That worked like a charm! Many thanks. But how comes,
this sort of behaviour on systems with massive catalogs
(millions of tables and indexes). Could that be your problem?
cheers
andrew
--
Sent via pgsql-performance mailing list (pgsql-performance@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-performance
during the day but less active during night
I think that the only only thing where Postgres is weak, is in this
area (table and index bloat).
For some reason for the same amount of data every day postgres consume
a little more.
Check out pg_reorg.
cheers
andrew
--
Sent via pgsql
,
indexes included. See the description of ACCESS EXCLUSIVE lock at
<http://www.postgresql.org/docs/current/static/explicit-locking.html>
cheers
andrew
--
Sent via pgsql-performance mailing list (pgsql-performance@postgresql.org)
To make changes to your subscription:
http://www.postgres
Is your network link between server and client across the public internet?
You need to check bandwidth and latency characteristics of your network.
A simple test run following on server host and run it again on the client
host.
time psql [connect details] -c 'select now()'
I access postgresql d
t is. The word "primarily" is not just a noise word here.
The fact that we have options to do other things doesn't mean that its
primary design goal has changed.
cheers
andrew
--
Sent via pgsql-performance mailing list (pgsql-performance@postgresql.org)
To make changes to your
u joining this table (or an extract from it) to
itself?
In any case, you could almost certainly recast it and have it run fast
by first filtering on the tracking number.
cheers
andrew
--
Sent via pgsql-performance mailing list (pgsql-performance@postgresql.org)
To make changes to your subs
ESS CORRECTION')
;
Or probably something way simpler but I just did this fairly quickly and
mechanically
cheers
andrew
--
Sent via pgsql-performance mailing list (pgsql-performance@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-performance
ed CTEs a LOT precisely because this
behaviour lets me get better plans. Without that I'll be back to using
the "offset 0" hack.
cheers
andrew
--
Sent via pgsql-performance mailing list (pgsql-performance@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-performance
d to have big red warnings all over then release notes,
since a lot of people I know will need to do some extensive remediation
before moving to such a release.
cheers
andrew
--
Sent via pgsql-performance mailing list (pgsql-performance@postgresql.org)
To make changes to your subscription:
http
On 11/21/2012 09:59 AM, Tom Lane wrote:
Andrew Dunstan writes:
If we're going to do it can we please come up with something more
intuitive and much, much more documented than "OFFSET 0"? And if/when we
do this we'll need to have big red warnings all over then release n
t all.
Then you have to unset it again, which is ugly. You might even want it
applying to *part* of a query, not the whole thing, so this strikes me
as a dead end.
cheers
andrew
--
Sent via pgsql-performance mailing list (pgsql-performance@postgresql.org)
To make changes to your subscri
)
2. WITH NO FENCE foo AS (SELECT ...)
3. WITH NOT FENCE foo AS (SELECT ...)
I loke the firsat variant, but the 3rd is
most SQL standardish!
As Tom (I think) pointed out, we should not have a syntax tied to CTEs.
cheers
andrew
--
Sent via pgsql-performance mailing list (pgsql-p
. You would normally expect maintenance_work_mem to be
higher - sometimes much higher.
Apart from that, it's going to be impossible to tell what your problem
is without seeing actual slow running queries and their corresponding
explain analyse output.
cheers
andrew
--
Sent via
On 12/05/2012 11:51 AM, Jean-David Beyer wrote:
I thought that postgreSQL did its own journalling, if that is the
proper term, so why not use an ext2 file system to lower overhead?
Postgres journalling will not save you from a corrupt file system.
cheers
andrew
--
Sent via pgsql
Is there a performance downside to setting track_activity_query_size to
a significantly larger value than the default 1024 (say 10240), given
that there's plenty of memory to spare?
cheers
andrew
--
Sent via pgsql-performance mailing list (pgsql-performance@postgresql.org)
To make ch
knows a JDBC or a multiplatform code that let read the delete
rows of a table without writing of a table file?
This isn't a performance related question. Please ask on the correct
list (probably pgsql-general).
cheers
andrew
--
Sent via pgsql-performance mailing list (pgsql-perfor
encourage such scans that's a but less violent than this?
cheers
andrew
--
Sent via pgsql-performance mailing list (pgsql-performance@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-performance
On 12/12/2012 04:32 PM, Tom Lane wrote:
Andrew Dunstan writes:
A client is testing a migration from 9.1 to 9.2, and has found that a
large number of queries run much faster if they use index-only scans.
However, the only way he has found to get such a plan is by increasing
the seq_page_cost
On 12/12/2012 05:12 PM, Andrew Dunstan wrote:
On 12/12/2012 04:32 PM, Tom Lane wrote:
Andrew Dunstan writes:
A client is testing a migration from 9.1 to 9.2, and has found that a
large number of queries run much faster if they use index-only scans.
However, the only way he has found to get
timates to be out by several orders of
magnitude. Guaranteeing estimates within bounded accuracy and in a given
short amount of time (you don't want your planning time to overwhelm
your execution time) isn't possible.
cheers
andrew
--
Sent via pgsql-performance mailing lis
s=1)
Hash Cond:
(customerdetails.customerid = entity.id)
Well, it looks like it's choosing a join order that's quite a bit
different from the way the query is expressed, so the OP might need to
play around with forcing the join order some.
cheers
andrew
--
S
seen anything like this?
cheers
andrew
--
Sent via pgsql-performance mailing list (pgsql-performance@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-performance
On 12/14/2012 02:56 PM, Tom Lane wrote:
Andrew Dunstan writes:
One of my clients has an odd problem. Every so often a backend will
suddenly become very slow. The odd thing is that once this has happened
it remains slowed down, for all subsequent queries. Zone reclaim is off.
There is no IO or
On 12/26/2012 11:03 PM, Jeff Janes wrote:
On Fri, Dec 14, 2012 at 10:40 AM, Andrew Dunstan
wrote:
> One of my clients has an odd problem. Every so often a backend will
suddenly
> become very slow. The odd thing is that once this has happened it
remains
> slowed down, for all s
gger. Does it by any chance use 'execute'?
cheers
andrew
--
Sent via pgsql-performance mailing list (pgsql-performance@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-performance
1));
And there you have it. Constraint exclusion does not work in cases like
this. It only works with static expressions (such as a literal date in
this case).
cheers
andrew
--
Sent via pgsql-performance mailing list (pgsql-performance@postgresql.org)
To make changes to your subscription
301 - 400 of 471 matches
Mail list logo
