postgres 20 0 24.722g 14812 12956 S 0.3 0.0 0:07.36
> postgres
>
>
> 9068 postgres 20 0 24.722g 6380 4232 S 0.3 0.0 0:02.15
> postgres
>
>
> 9065 postgres 20 0 24.727g 10368 3516 S 0.0 0.0 0:04.24
> postgres
>
>
> 9066 postgres 20 0 24.722g 4100 2248 S 0.0 0.0 0:06.04
> postgres
>
>
> 9067 postgres 20 0 24.722g 4100 2248 S 0.0 0.0 0:01.37
> postgres
>
>
> 9069 postgres 20 0 161740 4596 2312 S 0.0 0.0 0:04.48
> postgres
>
> What’s wrong with this? There isn’t something wrong in RAM usage?
>
> Thank you all
>Pietro
>
--
Andrew W. Kerber
'If at first you dont succeed, dont take up skydiving.'
It should solve your problems.
If they are going to keep the client connections open, they would need
to run pgbouncer in statement or transaction mode.
cheers
andrew
--
Sent via pgsql-performance mailing list (pgsql-performance@postgresql.org)
To make changes to your subscrip
text. Rendering jsonb as text
to the client involves a lot more processing.
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
he, 1.6GHz CPU,
linux 14.04 OS, 8GB RAM.
You should be using a cursor.
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
Please do not cross-post on the PostgreSQL lists. Pick the most
appropriate list to post to and just post there.
cheers
andrew
--
Sent via pgsql-performance mailing list (pgsql-performance@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql
the
entire application/OS/anything is no issue for me—there’s no data for
me to lose.
Thanks!
Read all of this chapter.
<http://www.postgresql.org/docs/current/static/backup.html>
cheers
andrew
--
Sent via pgsql-performance mailing list (pgsql-performance@postgresql.org)
To ma
nment. Linux/Solaris/FreeBSD do not suffer
from this issue in nearly the same manner.
jD
You might consider a CLUSTER or VACUUM FULL to re-write the table with
less fragmentation.
Or pg_repack if you can't handle the lockup time that these involve.
cheers
andrew
--
Sent via pgsql
update rewrites the whole row, not just the updated columns.
I think you are overthinking it.
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
now and making that turn a string
into a number if possible seems to me to be going in the wrong direction.
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
But I'm not sure how we do that except in a really ugly and ad-hoc
fashion.
I would be inclined to add the operator and see how cumbersome people
find it. I suspect in many cases it might be sufficient.
cheers
andrew
--
Sent via pgsql-performance mailing list (pgsql-performance@postgres
ml>
Second, the last test for fd.creation_time in your query seems
redundant. Could you not rewrite it as something this?:
where fd.creation_time <= '2011-11-07 10:39:07.285022+08'
and (fd.creation_time < '2011-11-07 10:39:07.285022+08'
or fd
On 11/03/2014 03:24 PM, Tom Lane wrote:
Andrew Dunstan writes:
andrew=# do $x$ declare r abc; begin for i in 1 .. 1000 loop
select 'a','b',i into r.x,r.y,r.z; end loop; end; $x$;
DO
Time: 63731.434 ms
andrew=# do $x$ declare r abc; begin fo
I found out today that direct assignment to a composite type is (at
least in my test) about 70% faster than setting it via SELECT INTO. That
seems like an enormous difference in speed, which I haven't really been
able to account for.
Test case:
andrew=# \d abc
INNER JOIN "public"."lookup" "romeo_bravo" ON ("papa_four"."quebec" =
"romeo_bravo"."quebec")
LEFT JOIN "public"."juliet_two" "juliet_two" ON ("foxtrot_india&qu
assume no big performance differences?
Thanks alot!
Emi
Why do you need to ask if you already have the answer? Depesz is right.
cheers
andrew
--
Sent via pgsql-performance mailing list (pgsql-performance@postgresql.org)
To make changes to your subscription:
http://www.postgresql.or
etely the wrong forum for this query.
usage questions should be on pgsql-general.
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
ortunately,
posgtress does not tell me where the bottleneck is. Is this is defensively
not the disk IO.
This is when you dig out tools like perf, maybe.
cheers
andrew
--
Sent via pgsql-performance mailing list (pgsql-performance@postgresql.org)
To make changes to your subscription:
ht
on Windows". shared_buffers above
512Mb causes performance to degrade on Windows, while that threshold is
much higher on *nix.
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
vents table, even though this would feel a little bit like a hack.
Any insights would be greatly appreciate.
-- AWG
On Tue, Apr 08, 2014 at 09:55:38AM -0400, Tom Lane wrote:
> "Andrew W. Gibbs" writes:
> > A very common query against this table is of the form...
>
> &g
Your understanding of the utility of multi-part indices does not jive
with my own.
While I agree that a partial index might be in order here, that ought
just be a performance optimization that lowers the footprint of the
index from an index size and index maintenance standpoint, not
something that
I have a fairly large table (~100M rows), let's call it "events", and
among other things it has a couple of columns on it, columns that
we'll call entity_type_id (an integer) and and published_at (a
timestamp). It has, among others, indices on (published_at) and
(entity_type_id, published_at).
A
On 12/28/2013 08:46 AM, ankush upadhyay wrote:
On Sat, Dec 28, 2013 at 6:50 PM, Andrew Dunstan <mailto:and...@dunslane.net>> wrote:
On 12/28/2013 12:19 AM, ankush upadhyay wrote:
Hello All,
I am using multi tenant system and doing performance testing
usually use the term "multi-tenancy" to refer to different postgres
instances running on the same machine, rather than different databases
within a single instance of postgres. So lease describe your setup in
more detail.
cheers
andrew
--
Sent via pgsql-performance mailing list (pgsql-p
ss.
Check this for example:
http://www.depesz.com/2010/03/18/profiling-stored-proceduresfunctions/
Also, the auto-explain module can peer inside functions. See
<http://www.postgresql.org/docs/current/static/auto-explain.html>
cheers
andrew
--
Sent via pgsql-performance mailing li
Not-pre-allocated disk-file backed is just about the worst case in my
experience.
Try pre-allocated VirtIO disks on an LVM volume group - you should get
much better performance.
cheers
andrew
--
Sent via pgsql-performance mailing list (pgsql-performance@postgresql.org)
To make changes to
be your best
bet. Depends a bit on your application and your workload. And yes, I've
used it. Full disclosure: I have done work paid for by Heroku.
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
mong others.) Pretty much all of these are VM based, and can be
suitable for many workloads.
Maybe the advice is a bit out of date.
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
y we don't have
transaction_timeout, or maybe transaction_idle_timeout.
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
irrelevant to the aggregation.
This gets hard when queries are very complex, and harder still when the
query is written by a query generator. But a good generator should not
just say "grouo by everything that's not aggregated" and think it's
doing a good job. In your case it should be relatively straightforward.
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
ite high, especially on a 48Gb box. What
happens if you dial that back to, say, 12Gb?
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
;xmin advance
these days and thus might help to reduce the impact of the longrunning
transactions.
Otherwise you will have to shorten those...
Yeah, we're looking at eliminating them.
cheers
andrew
--
Sent via pgsql-performance mailing list (pgsql-performance@postgresql.org)
To ma
gside this
one.
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
rs
+ 0.25% postgres [.] pg_verify_mbstr_len
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
changing the sort order, because those things would require processing
tables where the type is used, unlike the simple things. But neither of
these is required for typical use cases. For most uses of this kind they
are very efficient both in storage and processing.
cheers
andrew
--
Sent v
Hstore and JSON are
not different in this respect.
You should test the storage effects with your data. On 9.2 for your data
hstore might be a better bet, since in 9.2 hstore has more operators
available natively.
cheers
andrew
--
Sent via pgsql-performance mailing list (pgsql-performance
x27;t given us nearly enough information about your setup. We'd
need to see your configuration settings and have some details of the
machine and where connections are coming from to diagnose it further.
cheers
andrew
--
Sent via pgsql-performance mailing list (pgsql-performance@postgresql.or
by, etc.
No, I don't want to use orm.
It's a matter of taste. Pretty much every PL has facilities for
constructing and running dynamic sql. PLPgsql ,PLPerl, PLV8 ...
cheers
andrew
--
Sent via pgsql-performance mailing list (pgsql-performance@postgresql.org)
To make changes t
ou have nobody to blame but
yourself. There's a reason EDB haven't marked their function immutable -
it's not.
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
nless you assume that cache misses will be higher for random
reads than for sequential reads.
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
t cases no more than a handful for any given
table would be required.
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 04/22/2013 07:31 AM, pradeep singh wrote:
Hi,
I am using postgresql 8.1 DB.
Why are you using a release of Postgres that is way out of date and
unsupported?
cheers
andrew
--
Sent via pgsql-performance mailing list (pgsql-performance@postgresql.org)
To make changes to your
d and planned each time.
You should expect it to be quite a bit slower, and avoid using EXECUTE
wherever possible.
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
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
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
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
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
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
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
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
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
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
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
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
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
. 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
)
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
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
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
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
Postgres Performance Wizards,
I am a few years into developing and operating a system underpinned by
Postgres that sees the arrival a significant number of events around
the clock, not an epic amount of data, but enough to be challenging to
me, in particular when system downtime is not very palata
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
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
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
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
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
,
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
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
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
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,
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
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
, 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
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
&
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
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
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
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
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
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
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 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 (
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
, 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
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
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
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
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
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
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:
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
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
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
On 02/04/2011 02:32 AM, da...@lang.hm wrote:
when a copy command is issued, I assume that there is some indication
of how much data is going to follow.
No of course there isn't. How would we do that with a stream like STDIN?
Read the code.
cheers
andrew
--
Sent via
"misunderestimate" more in the future when talking about planner
errors. Might even try to slip it into the docs at some point in the
future and see if anybody catches it.
My wings take dream ...
cheers
andrew
--
Sent via pgsql-performance mailing list (pgsql-performance@postgresql.or
-- were planned in from the beginning.
Londiste aimed to be simpler, so it would be interesting to see
whether those features could be incorporated without the same
complication.
A
--
Andrew Sullivan
a...@crankycanuck.ca
--
Sent via pgsql-performance mailing list (pgsql-performance@postgresql.
duplicate key of slony
> meta-data were as this was a duplicate key of one of my table's primary
> key.
This really ought to be impossible -- Slony just speaks standard SQL
statements between nodes. But I won't say there's no possible bug
there. Your best bet is the Slony lis
s also much handier as
reference material than Slony's (which is, in my experience, a little
hard to navigate if you don't already know the system pretty well).
A
--
Andrew Sullivan
a...@crankycanuck.ca
--
Sent via pgsql-performance mailing list (pgsql-performance@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-performance
>>>>> "Tom" == Tom Lane writes:
> Andrew Gierth writes:
>> Type-dependent selection of operators has already been done as
>> part of parse analysis, no? And the domain -> base conversion is
>> purely a relabelling, no? So what semantic
eady been done as part of
parse analysis, no? And the domain -> base conversion is purely a
relabelling, no? So what semantic change is possible as a result?
--
Andrew (irc:RhodiumToad)
--
Sent via pgsql-performance mailing list (pgsql-performance@postgresql.org)
To make changes to you
1 - 100 of 471 matches
Mail list logo
