some more pages will need
registering. So the behavior you are seeing is expected.
--
Alvaro Herrera (<[EMAIL PROTECTED]>)
"We are who we choose to be", sang the goldfinch
when the sun is high (Sandman)
---(end of broadcast)---
say, with
some boolean in the call info struct) on which it returns planning data;
thus the planner can call the function itself. The hard part would be
figuring out how to do it without breaking backwards compatibility with
functions that don't know how to handle that. (And how to do
estimator
could be "return 1000".
--
Alvaro Herrera (<[EMAIL PROTECTED]>)
"A wizard is never late, Frodo Baggins, nor is he early.
He arrives precisely when he means to." (Gandalf, en LoTR FoTR)
---(end of broadcast)---
T
(id) = 3 and expensive_image_function(img)
> The idea, of course is to weight the expensive function so it was
> pushed to the end of the execution.
So there was only a constant cost associated with the function? No
estimator function, for example?
--
Alvaro Herrera (<[EMAIL PROTECTED]>)
were to design "open source" disk controllers and disks.]
--
Alvaro Herrera (<[EMAIL PROTECTED]>)
"La fuerza no está en los medios físicos
sino que reside en una voluntad indomable" (Gandhi)
---(end of broadcast)
and other back-to-front for
movement? Because if it doesn't work this way, it wouldn't relabel
(change Xmin/Xmax) tuples in early pages. Or does it do something
different?
I know maintenance_work_mem is used for storing TIDs of to-be-moved
tuples for index cleanup ... how does it
un on the three enormous files:
>
> $ /usr/local/bin/oid2name -d smt -o 160779
> From database "smt":
> Filenode Table Name
> ------
Try -f instead of -o ...
--
Alvaro Herrera (<[EMAIL PROTECTED]>)
"World domination is proceeding according t
On Fri, Apr 22, 2005 at 02:06:15AM +0200, Enrico Weigelt wrote:
> do foreign keys have any influence on performance (besides slowing
> down huge inserts) ? do they bring any performance improvement ?
No. They only cause additional tables to be visited to enforce them.
--
Alvaro H
load you expect in
production.
What happens if you execute the query more times? Do the times stay the
same as the second run?
--
Alvaro Herrera (<[EMAIL PROTECTED]>)
"Use it up, wear it out, make it do, or do without"
---(end of broadcast)--
f them.
--
Alvaro Herrera (<[EMAIL PROTECTED]>)
"Always assume the user will do much worse than the stupidest thing
you can imagine."(Julien PUYDT)
---(end of broadcast)---
TIP 5: Have you che
possible)?
Well, recycling is actually a *good* thing -- it saves you from having
to remove WAL segment files and allocate new files for the new logs. So
what you really want doesn't have anything to do with the recycling
itself, but rather with the simultaneous checkpoint that's goin
ating more checkpoint segments (which can eat a
> lot of disk space -- requirements are 16mb*(2 * segments +1) ) will prevent
> this problem.
Hmm? I disagree -- it will only make things worse when the checkpoint
does occur.
--
Alvaro Herrera ()
"Lo esencial es invisible par
gt; Am I Right?
No, they weren't when this tip was written. As of 8.0 however this tip
is no longer the complete truth; we do allow cross-type index scans.
--
Alvaro Herrera ()
"I suspect most samba developers are already technically insane...
Of course, since many of them are
pected.
I assume the MySQL guys would tell you to rewrite the queries in certain
ways to make it go faster (just like the Postgres guys tell people to
rewrite certain things when they hit Postgres limitations.)
--
Alvaro Herrera ()
"I would rather have GNU than GNO
r manager changes in
8.0 and later in 8.1 -- we saw extensive redesign of the bufmgr on both,
so the behavior may have changed. If you wanna test, I'm sure lots of
people here will be interested in the results.
--
Alvaro Herrera ()
"This is a foot just waiting to be sh
one
version can be painful already -- migrating three versions on one shot
might be a nightmare. OTOH it's much better to pay the cost of
migration once rather than three times ...)
--
Alvaro Herrera ()
"The Postgresql hackers have what I call a "NASA space shot" mentality.
Qui
Maybe you need a REINDEX, if you have indexes on that table. Try that,
coupled with the frequent VACUUM suggestion.
--
Alvaro Herrera ()
"World domination is proceeding according to plan"(Andrew Morton)
---(end of broadcast)---
On Mon, Jul 04, 2005 at 10:57:29AM +0200, Enrico Weigelt wrote:
> * Alvaro Herrera <[EMAIL PROTECTED]> wrote:
> > On Mon, Jul 04, 2005 at 02:17:47AM +0200, Enrico Weigelt wrote:
> > > * David Mitchell <[EMAIL PROTECTED]> wrote:
> > > > Perhaps if
ktop with PIV 1.8 GHz, two disks with data and index's on each disk
> - it is solved in 4h for W2K
Do you have the same locale settings on all of them?
--
Alvaro Herrera ()
"We are who we choose to be", sang the goldfinch
when the sun is high (Sandman)
ng and recreating the users?
>
> Never tried to go backwards before but:
>
> alter user foo with encrypted password '';
I think you use NULL as password to ALTER USER.
--
Alvaro Herrera ()
"Y eso te lo doy firmado con mis lágrimas" (Fiebre de
st of them.
I'd guess it's stuck on some lock. Try that EXPLAIN, and when it
blocks, watch the pg_locks view for locks not granted to the process
executing the EXPLAIN. Then check what else is holding the locks.
--
Alvaro Herrera ()
"La rebeldía es la virtud original del homb
an allow old data to appear in
files after a crash and journal recovery.
--
Alvaro Herrera ()
Officer Krupke, what are we to do?
Gee, officer Krupke, Krup you! (West Side Story, "Gee, Officer Krupke")
---(end of broadcast)-
nding on dead
tuple rate.)
--
Alvaro Herrera ()
"World domination is proceeding according to plan"(Andrew Morton)
---(end of broadcast)---
TIP 9: In versions below 8.0, the planner will ignore your desire to
choose an index scan if
d very long transactions, but
apparently this isn't your problem.
> Isn't it normal to have processes that keep a single database
> connection open for days at a time?
I guess it depends on exactly what you do with it. I know of at least
one case where an app keeps a connection
On Thu, Jul 14, 2005 at 08:28:24PM -0400, Alvaro Herrera wrote:
> On Fri, Jul 15, 2005 at 09:42:12AM +1000, Alison Winters wrote:
>
> > INFO: Pages 1221: Changed 3, reaped 256, Empty 0, New 0; Tup 108137: Vac
> > 4176, Keep/VTL 108133/108133, UnUsed 19, MinLen 84, M
n't believe it's the raid. I've tested this by
> moving the database to the mirrors software raid where the root is
> found and onto the the SATA raid. Neither relieved the IO problems.
What filesystem is this?
--
Alvaro Herrera ()
Si no sabes adonde vas, es muy
ckpoints were 5 minutes apart. With fsync off, there's no
work _at all_ going on, not just the WAL -- heap/index file fsync at
checkpoint is also skipped. This is no good.
--
Alvaro Herrera ()
"In a specialized industrial society, it would be a disaster
to have kids running around lo
; ensure any page mappings are invalidated.
There are no mmap/munmap calls in our code. The problematic code is
probably somewhere in the libc. Maybe it'd be useful to figure out
where it's called and why, with an eye on working around that.
--
Alvaro Herrera ()
"I love the P
into b values (1);
-- hangs
If I commit on session 1, session 2 is unlocked.
This is a known problem, solved in 8.1. A workaround for previous
releases is to defer FK checks until commit:
create table b (a int references a initially deferred);
--
Alvaro Herrera ()
Dios hizo a Adán, pero fue Eva qui
On Mon, Aug 15, 2005 at 10:25:47AM +0200, Magnus Hagander wrote:
> SQL 2005 has "MVCC" (they call it something different, of course, but
> that's basicallyi what it is)
Interesting; do they use an overwriting storage manager like Oracle, or
a non-overwriting one like
ouple of times and I don't know the answer: what
happens if you give XLog a single drive (unmirrored single spindle), and
that drive dies? So the question really is, should you be giving two
disks to XLog?
--
Alvaro Herrera ()
"[PostgreSQL] is a great group; in my opinion it is THE best
nflicted
I/O to be interleaved by normal query execution.
Sadly (for you), I think the cost-based vacuum delay feature was only
introduced in 8.0.
--
Alvaro Herrera ()
Officer Krupke, what are we to do?
Gee, officer Krupke, Krup you! (West Side Story, "Gee, Officer Krupke")
> necessarily a measurable amount, mind you, maybe even zero because
> > of padding issues.)
>
> You are right, all this time I thought there was a 4 byte penalty for
> storing varchar type and not in char :(. So there is no reason at all
> to use the char type?
Other th
e's no saving at all by doing that. Quite the
opposite really, because with char(x) you store the padding blanks,
which are omitted with varchar(x), so less I/O (not necessarily a
measurable amount, mind you, maybe even zero because of padding issues.)
--
Alvaro Herrera -- Valdivia, Chile
ones
> > that grow to unmanageable sizes (and that I can drop old child tables
> > instead of delete/vacuum).
>
> Perhaps I missed something in this thread, but don't forget
> you still need vacuum to reclaim XIDs.
Yes, but if you are going to drop the partition before
power is restored, the RAID controller will complete the writes
> to disk. If the battery does not last through the outage, the data is
> lost.
Just curious: how long are the batteries supposed to last?
--
Alvaro Herrera -- Valdivia, Chile Architect, www.EnterpriseDB.com
Hi! I'm
version of postgres was the last version that had
> the index bloat problem?
The worst problems were solved in 7.4. There are problems in certain
limited circumstances even with current releases.
--
Alvaro Herrera http://www.amazon.com/gp/registry/DXLWNGRJD34
"The ability
2 column there must be 2
bytes of padding.
If you had two consecutive int2 fields you would save some the space.
Or int2/bool/bool (bool has 1-byte alignment), etc.
This assumes you are in a tipical x86 environment ... in other
environments the situation may be different.
--
Alvaro Herrera
> to make sure XLogInsert always had some buffer space to
> play with.
If you are using a single connection, you are wasting lots of cycles
just waiting for the disk to spin. Were you to use multiple
connections, some transactions could be doing some useful work while
others are wa
onf has any way to determine whether a libc
> function represents a native kernel call or not ...
The problem kernels would be Linux 2.0, which I very much doubt is going
to be present in to-be-deployed database servers.
Unless someone runs glibc on top of some other kernel, I guess. Is this
a
nded number of
transactions, each forcing the other to do some index cleanup. This is
not acceptable.
Plus, it would be very hard to implement, and a very wide door to bugs.
--
Alvaro Herrerahttp://www.advogato.org/person/alvherre
"Et put se mouve" (Galileo Ga
e a lot of free swap,
judging by a nearby post. But maybe the problem is that the swap is
completely used too, and so the OOM killer (is this Linux?) comes around
and kills the appserver.
Certainly the problem is not the caching. You should be monitoring when
and why the appserver dies.
--
Alv
> work_mem = 256000
Interesting that you set both sort_mem and work_mem. Do you realize
that the former is an obsolete name, and currently a synonym for the
latter? Maybe the problem is that you are using too much memory for
sorts, forcing swap usage, etc.
--
Alvaro Herrera http://w
ed bloat in pg_class, pg_attribute, or other system catalogs.
You may want to make sure these are vacuumed often.
--
Alvaro Herrerahttp://www.CommandPrompt.com/
PostgreSQL Replication, Consulting, Custom Development, 24x7 support
---(end o
re_ you do any
investment in hardware, because later those may prove unnecessary.
--
Alvaro Herrerahttp://www.CommandPrompt.com/
The PostgreSQL Company - Command Prompt, Inc.
---(end of broadcast)---
TIP 3: Have you c
ting to complicate the schema -- I was actually thinking
in systems where some queries are not using indexes, some queries are
plain wrong, etc. Buying a very expensive RAID and then noticing that
you just needed to create an index, is going to make somebody feel at
least somewhat stupi
ally support the
idea of running Postgres on one of those things.
There's certainly true in that the memory requirements have increased a
bit, but I don't think it really qualifies as "high end" even on 8.1.
--
Alvaro Herrera Developer, http://www.Pos
ry plan and the
optimizer is not using it, by all means submit it so that developers can
take a look at how to improve the optimizer.
--
Alvaro Herrerahttp://www.CommandPrompt.com/
The PostgreSQL Company - Command Prompt, Inc.
---(end of broadcast)---
TIP 6: explain analyze is your friend
it
critically and let us know so we can improve it.
http://www.postgresql.org/docs/8.1/static/maintenance.html#AUTOVACUUM
Maybe what you need is to lower the "vacuum base threshold" for tables
that are small.
--
Alvaro Herrerahttp://www.CommandPrompt.com
going
anywhere -- you should have ten times that at the very least.
--
Alvaro Herrerahttp://www.CommandPrompt.com/
PostgreSQL Replication, Consulting, Custom Development, 24x7 support
---(end of broadcast)---
TIP 3: H
you execute queries from the log, one after another? That may not
be a representative test -- try sending multiple queries in parallel, to
see how the server would perform in the real world.
--
Alvaro Herrerahttp://www.CommandPrompt.com/
The PostgreSQL Company - Command
ith no sleep in between, right?
I wouldn't expect a normal OLTP operation to be like this. (If it is
you have a serious shortage of hardware ...)
--
Alvaro Herrerahttp://www.CommandPrompt.com/
PostgreSQL Replication, Consulting, Custom Development, 24x7 suppo
don't know. The
integrated one? Yes it is; and you can set autovacuum-specific values
in postgresql.conf and table-specific values (used for autovacuum only)
in pg_autovacuum.
--
Alvaro Herrerahttp://www.CommandPrompt.com/
The PostgreSQL Company
Tom Lane wrote:
> Alexander Staubo <[EMAIL PROTECTED]> writes:
> > No, fsync=on. The tps values are similarly unstable with fsync=off,
> > though -- I'm seeing bursts of high tps values followed by low-tps
> > valleys, a kind of staccato flow indicative of a write caching being
> > filled up
for all transactions, even those currently
running.
> What happens to pg_xlogs when a transaction updates M of rows/tables and
> runs for hours?
They get recycled as the update goes.
--
Alvaro Herrerahttp://www.CommandPrompt.com/
The PostgreSQL Company - Com
ually it has been suggested that a combination of ext2 (for WAL) and
ext3 (for data, with data journalling disabled) is a good performer.
AFAIK you don't want the overhead of journalling for the WAL partition.
--
Alvaro Herrerahttp://www.CommandPrompt.co
2". In previous releases, you could vacuum
that queue table until you were blue on the face, but it would achieve
nothing because it would consider that the dead tuples were visible to a
running transaction: that running the vacuum on the large table. This
is an annoyance that was fixed in 8
gt; (2) Reconsider whether last-vacuum-time should be sent to the collector
> unconditionally.
(2) seems a perfectly reasonably answer, but ISTM (1) would be good to
have anyway (at least in HEAD).
--
Alvaro Herrerahttp://www.CommandPrompt.com/
The Postgr
we actually get rid of pg_class entries for temp tables. Maybe
creating a "temp pg_class" which would be local to each session? Heck,
it doesn't even have to be an actual table -- it just needs to be
somewhere from where we can load entries into the rel
so restrict the query to reference exactly one table, since join
* conditions can't be handled reasonably. (We could perhaps handle a
* query containing cartesian-product joins, but it hardly seems worth the
* trouble.)
*/
so you should keep using your hand-written order b
Luke Lonergan wrote:
> Adam,
>
> This optimization would require teaching the planner to use an index for
> MAX/MIN when available. It seems like an OK thing to do to me.
This optimization already exists, albeit for queries that use a single
table.
--
Al
Jim C. Nasby wrote:
> I'll generally start with a cost delay of 20ms and adjust based on IO
> utilization.
I've been considering set a default autovacuum cost delay to 10ms; does
this sound reasonable?
--
Alvaro Herrerahttp://www.CommandPrompt
really "1-1000x"? I bet this one is more impressive in
PHB terms.
--
Alvaro Herrerahttp://www.CommandPrompt.com/
PostgreSQL Replication, Consulting, Custom Development, 24x7 support
---(end of broadcast)-
Luke Lonergan wrote:
> Alvaro,
>
> On 1/30/07 9:04 AM, "Alvaro Herrera" <[EMAIL PROTECTED]> wrote:
>
> >> (Incidentally I'm not sure where 2-5x comes from. It's entirely dependant
> >> on
> >> your data distribution. It's not
entries should be
getting dropped at some point in both releases. Maybe there's a bug
preventing that in 8.2?
--
Alvaro Herrerahttp://www.CommandPrompt.com/
PostgreSQL Replication, Consulting, Custom Development, 24x7 support
---(end of b
40ADDE5141006071B233410020D1D851410040019B33410020D1D85141'::geometry)
>
> Is it normal I have no recheck cond and the index cond of Bitmap Index
> Scan is in the filter? Is it also a consequence of the code you
> pointed?
It is in the filter, is it not? Havi
Gauri Kanekar escribió:
> I want the planner to ignore a specific index.
> I am testing some query output. For that purpose i dont want the index.
> I that possible to ignore a index by the planner.
Sure:
BEGIN
DROP INDEX foo
SELECT
ROLLBACK
--
Alvar
has been tracked down to a bug in 8.1's Windows port. See
http://people.planetpostgresql.org/mha/index.php?/archives/134-8.1-on-win32-pgstat-and-autovacuum.html
--
Alvaro Herrerahttp://www.CommandPrompt.com/
PostgreSQL Replication, Consulting, Custom Developm
Mark Stosberg wrote:
> Alvaro Herrera wrote:
> > Mark Stosberg wrote:
> >> When I upgraded a busy database system to PostgreSQL 8.1, I was excited
> >> about AutoVacuum, and promptly enabled it, and turned off the daily
> >> vacuum process.
> >>
&g
l has been calling their server processors Xeon since Pentium
Pro's, at least.
--
Alvaro Herrerahttp://www.CommandPrompt.com/
The PostgreSQL Company - Command Prompt, Inc.
---(end of broadcast)---
TIP 3: Have you ch
the graphs from
the .nl magazine posted last year. I think this suggests that the
"MySQL deficiency" was rather a performance bug in Linux, not in MySQL
itself ...
--
Alvaro Herrerahttp://www.CommandPrompt.com/
The PostgreSQL Company - Command Prompt, I
_pattern_ops and related opclasses, right?
That helps for LIKE queries in non-C locales (though you do have to keep
almost-duplicate indexes).
--
Alvaro Herrerahttp://www.CommandPrompt.com/
PostgreSQL Replication, Consulting, Custom Development,
Mezei Zoltán wrote:
>
>
>
>
>
>
> Richard Huxton wrote:
>
>
>
> Re: [PERFORM] Deceiding which index to use
>
Would you mind instructing your mail system to skip converting your
text/plain messages to HTML? It's kind of ann
and hash joins, while the other plan seems
to be more elaborate -- I wonder if you have disabled bitmap scan, merge
joins, in 8.2? Try a SHOW enable_mergejoin in psql.
--
Alvaro Herrerahttp://www.CommandPrompt.com/
The PostgreSQL Company - Comm
tings where name like 'enable_%';
--
Alvaro Herrerahttp://www.CommandPrompt.com/
The PostgreSQL Company - Command Prompt, Inc.
---(end of broadcast)---
TIP 4: Have you searched our list
emove dead tuples that were
killed while the long vacuum was running -- unless you are in 8.2.
--
Alvaro Herrerahttp://www.CommandPrompt.com/
The PostgreSQL Company - Command Prompt, Inc.
---(end of broadcast)---
TIP 9:
Dimitri escribió:
> On Thursday 22 March 2007 14:52, Alvaro Herrera wrote:
> > Dimitri escribió:
> > > Folks,
> > >
> > > is there any constrains/problems/etc. to run several vacuum processes in
> > > parallel while each one is 'vaccuming' one
on belongs into
pgsql-hackers though, and any patches you may feel like submitting for
review should go to pgsql-patches.
--
Alvaro Herrerahttp://www.CommandPrompt.com/
PostgreSQL Replication, Consulting, Custom Development, 24x7 support
---(e
ase the fault probability.
... of individual disks, which is quite different from failure of a disk
array (in case there is one).
--
Alvaro Herrerahttp://www.CommandPrompt.com/
The PostgreSQL Company - Command Prompt, Inc.
---(end of broadcast)-
would have a spare disk to let the array controller replace
the broken one as soon as it breaks, but yeah, that would be more or
less the procedure. There is a way to defer the walk/drive until a more
convenient opportunity presents.
--
Alvaro Herrera
is index at the
top of the list, and restart the algorithm (after the sorting step of
course).
I think the concern about condition redundancy should be attacked
separately. How about just comparing whether they have common prefixes
of conditions? I admit I don't understand what would
ntioned approach to avoid the point of contention is to
have a "totals" record and have the triggers insert "deltas" records; to
get the sum, add them all. Periodically, take the deltas and apply them
to the totals.
--
Alvaro Herrerahttp://w
x27;s alternative to the pattern_ops index; it won't help you obtain a
plan faster than this one.
--
Alvaro Herrerahttp://www.CommandPrompt.com/
The PostgreSQL Company - Command Prompt, Inc.
---(end of broadcast)---
TIP 2: Don't 'kill -9' the postmaster
LYZE is like VACUUM, except that it also runs an ANALYZE
afterwards.
--
Alvaro Herrerahttp://www.CommandPrompt.com/
The PostgreSQL Company - Command Prompt, Inc.
---(end of broadcast)---
TIP 9: In versions below 8.0,
Steinar H. Gunderson wrote:
> On Tue, May 08, 2007 at 05:52:13PM -0400, Alvaro Herrera wrote:
> >> I am trying to follow a message thread. One guy says we should be running
> >> vacuum analyze daily and the other says we should be running vacuum
> >> multiple
earch.
A prefilter step eliminates all but the cheapest of those indexes using
the same set of WHERE conditions, to keep the effective value of N down in
scenarios where the DBA has created lots of partially-redundant indexes.
--
Alvaro Herrerahttp://www.CommandPro
ew
> blocks allocated). But of course the philosophy is where should it be
> done (ZFS or PostgreSQL).
Checksums on WAL are not optional in Postgres, because AFAIR they are
used to determine when it should stop recovering.
--
Alvaro Herrerahttp://www.CommandProm
open and
close those files as needed. I would actually expect it to cause extra
"system" load (as opposed to "user") rather than IO, but I'm not sure.
--
Alvaro Herrerahttp://www.CommandPrompt.com/
The PostgreSQL Company - Comm
n contrib, wasn't there? No
need to write one yourself.
AFAIR what it did was precisely to remember the numbers from the last
vacuum, which was cumbersome and not very effective (because they were
lost on restart for example). Also, the new autovac has some features
that the old one didn't
p.source_id
> AND tp.translation_id = t.translation_id
> AND t.language_id = l.language_id
> AND l.name = 'French' ;
Please provide an EXPLAIN ANALYZE of the query.
--
Alvaro Herrerahttp://www.CommandPrompt.com
l = true
> stats_row_level = true
> stats_reset_on_server_start = true
Stats are present on all databases. As for the name of the tables, try
pg_stat_user_tables and pg_stat_activity for starters. There are a lot
more; check the documentation or a \d pg_stat* in psql.
--
Alvaro Herrera
t? The natural conclusion would rather be to
> document the fact than REINDEX is needed after VACUUM FULL, isn't
> it?
Maybe, but we should also mention that CLUSTER is a likely faster
workaround.
--
Alvaro Herrerahttp://www.CommandPrompt.com
not
full) for most of your needs, and CLUSTER for the rare other cases. Of
course you would not pick an index at random each time, but rather keep
using the same one, which would supposedly be faster.
--
Alvaro Herrerahttp://www.CommandPrompt.com/
PostgreSQL Replic
Craig James wrote:
> Better yet, if you can stand a short down time, you can drop indexes on
> that column, truncate, then do 121 million inserts, and finally
> reindex. That will be MUCH faster.
Or you can do a CLUSTER, which does all the same things automatically.
--
Alvar
reater than 250
> tps, as long as you had >1 client providing input. Or was I wrong?
My impression is that you are correct in theory -- this is the "commit
delay" feature. But it seems that the feature does not work as well as
one would like; and furthermore, it is disabled by def
" in the actual index.
What would happen when you inserted a new tuple with just "miss"? You
would need to expand all the other tuples in the index.
--
Alvaro Herrera http://www.flickr.com/photos/alvherre/
"Puedes vivir solo una vez, pero si lo
of reindexing, because that will compact the
heap as well as the indexes).
Another recommendation is to upgrade to 8.2.4 which is faster and has
a better autovacuum.
--
Alvaro Herrerahttp://www.CommandPrompt.com/
The PostgreSQL Company - Command Prompt, Inc.
---
Peter T. Breuer escribió:
> I really think it would be worthwhile getting some developer to tell me
> where the network send is done in PG.
See src/backend/libpq/pqcomm.c (particularly internal_flush()).
--
Alvaro Herrerahttp://www.CommandPrompt.co
. We have two versions of our test
> environment one with production DB copy and second genereated with
> minimal data set and it is odd that update presented above on copy of
> production is executing 170ms but on small DB it executing 6s
How are you va
This will
get rid of any dead space that may be hurting your measurements.
--
Alvaro Herrerahttp://www.advogato.org/person/alvherre
"The Postgresql hackers have what I call a "NASA space shot" mentality.
Quite refreshing in a world of "weekend drag
1 - 100 of 449 matches
Mail list logo
