. The
third-party library (OpenBabel) has been tested pretty thoroughly by
me an others and has no memory corruption problems. All malloc's are
freed properly. Does that seem like a possibility?
Not really. palloc uses malloc underneath.
--
Alvaro Herrera Valdivia, Chile ICBM: S 39º 49' 18.1
Craig James wrote:
Alvaro Herrera wrote:
Craig James wrote:
Here is my guess -- and this is just a guess. My functions use a
third-party library which, of necessity, uses malloc/free in the
ordinary way. I suspect that there's a bug in the Postgres palloc()
code that's walking over memory
Craig James wrote:
Alvaro Herrera wrote:
Craig James wrote:
Alvaro Herrera wrote:
Craig James wrote:
Here is my guess -- and this is just a guess. My functions use a
third-party library which, of necessity, uses malloc/free in the
ordinary way. I suspect that there's a bug
:
http://www.postgresql.org/docs/8.3/static/storage-page-layout.html
--
Alvaro Herrera http://www.amazon.com/gp/registry/DXLWNGRJD34J
Siempre hay que alimentar a los dioses, aunque la tierra esté seca (Orual)
---(end of broadcast
stuff.
--
Alvaro Herrera http://www.amazon.com/gp/registry/CTMLCN8V17R4
La experiencia nos dice que el hombre peló millones de veces las patatas,
pero era forzoso admitir la posibilidad de que en un caso entre millones,
las patatas pelarían al hombre (Ijon Tichy
.
Perhaps you just have a maintenance_work_mem setting that's too large
for your server.
--
Alvaro Herrerahttp://www.advogato.org/person/alvherre
Uno puede defenderse de los ataques; contra los elogios se esta indefenso
---(end of broadcast
but not least, it would be *excelent* that this kind of optimization
would be posible without weird non standard sql sentences.
Right. If you can afford to sponsor development, it could make them a
reality sooner.
--
Alvaro Herrera Valdivia, Chile ICBM: S 39º 49' 18.1, W 73º 13' 56.4
You're
in question.
You do all three on the same tables? That seems pretty pointless. A
sole CLUSTER has the same effect.
Do I need to do a VACUUM FULL ANALYZE instead?
No.
--
Alvaro Herrera Valdivia, Chile ICBM: S 39º 49' 18.1, W 73º 13' 56.4
There was no reply (Kernel Traffic
- there are no deletes
The only other source of dead rows I can think is triggers ... do you
have any? (Not necessarily on this table -- perhaps triggers on other
tables can cause updates on this one).
Oh, rolled back COPY can cause dead rows too.
--
Alvaro Herrera http
.
(Actually it works even when you're not using mailing lists at all).
--
Alvaro Herrera http://www.amazon.com/gp/registry/CTMLCN8V17R4
If it wasn't for my companion, I believe I'd be having
the time of my life (John Dunbar)
---(end of broadcast
Trevor Talbot escribió:
On 11/13/07, Alvaro Herrera [EMAIL PROTECTED] wrote:
Jean-David Beyer wrote:
Andrew Sullivan wrote:
I'm not a private support organisation; please send your replies to the
list, not me.
Sorry. Most of the lists I send to have ReplyTo set, but a few do
queries,
whereas the other one is going to be used for = queries. So you need to
keep both indexes.
--
Alvaro Herrera http://www.amazon.com/gp/registry/5ZYLFMCVHXC
Officer Krupke, what are we to do?
Gee, officer Krupke, Krup you! (West Side Story, Gee, Officer Krupke
is actually with big tables, for which it
doesn't make much of a difference.
--
Alvaro Herrerahttp://www.CommandPrompt.com/
PostgreSQL Replication, Consulting, Custom Development, 24x7 support
---(end of broadcast
the table much more often, say every few minutes.
Your table is 2536 pages long, but it could probably be in the vicinity
of 700 ...
--
Alvaro Herrerahttp://www.CommandPrompt.com/
PostgreSQL Replication, Consulting, Custom Development, 24x7 support
our
lives a bit better (at least along a certain axis).
--
Alvaro Herrera http://www.PlanetPostgreSQL.org/
The problem with the future is that it keeps turning into the present
(Hobbes)
---(end of broadcast)---
TIP 6
vacuum_cost_limit = 100
Isn't this a bit high? What happens if you cut the delay to, say, 10?
(considering you've lowered the limit to half the default)
--
Alvaro Herrera Developer, http://www.PostgreSQL.org/
Someone said that it is at least an order of magnitude more
. (It's also much less of a problem in
8.2).
--
Alvaro Herrerahttp://www.CommandPrompt.com/
The PostgreSQL Company - Command Prompt, Inc.
---(end of broadcast)---
TIP 7: You can help support the PostgreSQL project
Ron St-Pierre wrote:
Alvaro Herrera wrote:
Ron St-Pierre wrote:
Okay, here's our system:
postgres 8.1.4
Upgrade to 8.1.10
Any particular fixes in 8.1.10 that would help with this?
I don't think so, but my guess is that you really want to avoid the
autovacuum bug which
that noise from vacuum and
make it appear on a view. 8.4 material all of this, of course.
--
Alvaro Herrera http://www.amazon.com/gp/registry/CTMLCN8V17R4
Estoy de acuerdo contigo en que la verdad absoluta no existe...
El problema es que la mentira sí existe y tu estás mintiendo
.
--
Alvaro Herrerahttp://www.CommandPrompt.com/
The PostgreSQL Company - Command Prompt, Inc.
---(end of broadcast)---
TIP 5: don't forget to increase your free space map settings
51788 940
postgres: autovacuum launcher process 51924 1236
postgres: stats collector process 22256 896
--
Alvaro Herrerahttp://www.CommandPrompt.com/
The PostgreSQL Company - Command Prompt, Inc
is
dealing with the several different ways of wrapping).
If there are any takers I would be very thankful.
--
Alvaro Herrerahttp://www.CommandPrompt.com/
PostgreSQL Replication, Consulting, Custom Development, 24x7 support
---(end
. If this weren't
misestimated, it wouldn't be using those nested loops.
--
Alvaro Herrerahttp://www.CommandPrompt.com/
PostgreSQL Replication, Consulting, Custom Development, 24x7 support
---(end of broadcast
.
--
Alvaro Herrera http://www.amazon.com/gp/registry/CTMLCN8V17R4
Este mail se entrega garantizadamente 100% libre de sarcasmo.
---(end of broadcast)---
TIP 4: Have you searched our list archives?
http
problem disappear...
I wonder if I should then periodically run a vacuum full --- say, once
a week? Once a month?
Never. What you need to do is make sure your FSM settings
(fsm_max_pages in particular) are high enough, and that you VACUUM (not
full) frequently enough.
--
Alvaro Herrera
not distinguish pages which have no live tuples from other pages, so
it has to load them all.
--
Alvaro Herrera http://www.amazon.com/gp/registry/CTMLCN8V17R4
[PostgreSQL] is a great group; in my opinion it is THE best open source
development communities in existence anywhere
be different because I've tuned the query planner's
parameters.
Why did you set enable_sort=off? It's not like sorting 9 rows is going
to take any noticeable amount of time anyway.
--
Alvaro Herrerahttp://www.advogato.org/person/alvherre
No hay hombre que no aspire a la
I should add, there are 6 back ends running on this disk array
(different servers and different data partitions) with these bgwriter
settings.
Maybe it is running deferred triggers or something?
--
Alvaro Herrerahttp://www.advogato.org/person/alvherre
I suspect most
, REINDEX does not rewrite tables. If there are dead tuples, they
will still be there after REINDEX.
cluster, otoh, rewrites the table into index order.
... excluding dead tuples, and then rewrites all the indexes.
--
Alvaro Herrerahttp://www.CommandPrompt.com
for
actual optimization (which happens to be a more normalized model), far
more effective than the partial indexes you are suggesting.
--
Alvaro Herrerahttp://www.CommandPrompt.com/
The PostgreSQL Company - Command Prompt, Inc.
---(end
performance improvements still to be
reported), but that doesn't help those poor users still on 8.2.
--
Alvaro Herrera http://www.amazon.com/gp/registry/DXLWNGRJD34J
Los dioses no protegen a los insensatos. Éstos reciben protección de
otros insensatos mejor dotados (Luis Wu, Mundo
it is vacuuming a table?
It causes I/O. Not sure what else you have in mind. vacuum_delay
throttles the I/O usage, at the expense of longer vacuum times.
--
Alvaro Herrerahttp://www.CommandPrompt.com/
PostgreSQL Replication, Consulting, Custom Development, 24x7
high I/O load. Maybe you should fix that.
--
Alvaro Herrerahttp://www.CommandPrompt.com/
PostgreSQL Replication, Consulting, Custom Development, 24x7 support
---(end of broadcast)---
TIP 9: In versions below 8.0
are transactions too. They just don't modify data.
--
Alvaro Herrerahttp://www.CommandPrompt.com/
PostgreSQL Replication, Consulting, Custom Development, 24x7 support
---(end of broadcast)---
TIP 4: Have you searched
Mikko Partio escribió:
Off-topic question: the documentation says that XID numbers are 32 bit.
Could the XID be 64 bit when running on a 64 bit platform? That would
effectively prevent wrap-around issues.
No, because they would take too much space in tuple headers.
--
Alvaro Herrera
that were just frozen,
but it will generate logs for tuples that weren't frozen. How many of
these there are, depends on how many tuples you inserted after the batch
that was just frozen.
If you want to freeze the whole table completely, you can you VACUUM
FREEZE.
--
Alvaro Herrera
of this thread.
I don't think you showed us the EXPLAIN ANALYZE results that Scott
requested.
--
Alvaro Herrerahttp://www.CommandPrompt.com/
PostgreSQL Replication, Consulting, Custom Development, 24x7 support
---(end of broadcast
second.
#autovacuum_vacuum_scale_factor = 0.4
#autovacuum_analyze_scale_factor = 0.2
These too. Try 0.1 for both and see how it goes.
In short, you need autovacuum to run _way more often_ than you are.
--
Alvaro Herrerahttp://www.advogato.org/person/alvherre
Un
that the table contains many different
values, which makes it turn the initial hashed aggregation into a sort
plus group aggregation. This allows the aggregation to use less memory.
As an exercise, see an EXPLAIN of the query, both before and after the
analyze, and study the difference.
--
Alvaro Herrera
anybody else has the same experience?
You haven't specified where the slowness is. Is it that connection
establishing is slower? Are queries slower? Is the hardware
comparable? Are the filesystems configured similarly?
--
Alvaro Herrera http://www.amazon.com/gp/registry
be slow.
--
Alvaro Herrera http://www.amazon.com/gp/registry/DXLWNGRJD34J
Puedes vivir solo una vez, pero si lo haces bien, una vez es suficiente
---(end of broadcast)---
TIP 2: Don't 'kill -9' the postmaster
a bug report ?
Were you able to show that turning off autovacuum removes the
performance problem?
--
Alvaro Herrerahttp://www.CommandPrompt.com/
PostgreSQL Replication, Consulting, Custom Development, 24x7 support
---(end of broadcast
)
- Hash Join (cost=1.34..3356.99 rows=28
width=145) (actual time=0.215..15.225 rows=414 loops=1)
Hash Cond: ((gra.codcor)::text =
((div.codite)::text || ''::text))
--
Alvaro Herrera http://www.amazon.com/gp/registry/CTMLCN8V17R4
Uno combate
for ShareLock on transaction 5098760; blocked by
process 21172.
What Postgres version is this?
--
Alvaro Herrerahttp://www.CommandPrompt.com/
The PostgreSQL Company - Command Prompt, Inc.
---(end of broadcast)---
TIP 6
not 100% sure.
That's correct (of course you need start_collector on as well). Most
likely, autovacuum is not even running.
--
Alvaro Herrerahttp://www.CommandPrompt.com/
The PostgreSQL Company - Command Prompt, Inc.
---(end of broadcast
Lock Id Combined Time (ns)
postgres`LWLockAcquire+0x1f0
postgres`CommitTransaction+0x104
Yeah, ProcArrayLock is pretty contended. I think it would be kinda neat
if we could split it up in partitions. This lock is quite particular
though.
--
Alvaro
Paul van den Bogaard wrote:
the manual somewhere states ... if archiving is enabled... To me this
implies that archiving can be disabled. However I cannot find the parameter
to use to get this result.
Archiving is disabled by not setting archive_command.
--
Alvaro Herrera
you are seeing a lower
number for some users and higher for others (simpler/more complex
queries).
This is just a guess though. No profiling or measuring at all, really.
--
Alvaro Herrera http://www.amazon.com/gp/registry/5ZYLFMCVHXC
How amazing is that? I call it a night
of tables (say 300k).
--
Alvaro Herrerahttp://www.CommandPrompt.com/
The PostgreSQL Company - Command Prompt, Inc.
---(end of broadcast)---
TIP 2: Don't 'kill -9' the postmaster
generate_series(1, 5000); truncate van_os;
times are closer to 8-13 ms.
I guess the difference is the amount of data that ext3 is logging on its
journal. My ext3 journal settings are default.
--
Alvaro Herrera Valdivia, Chile ICBM: S 39º 49' 18.1, W 73º 13' 56.4
¿Que diferencia tiene para los
smiley2211 wrote:
Thanks Tom and Scott...that worked for a NEW database but not on the original
SLOW database...meaning - I backed up the SLOW database and restored it to a
NEW database and the query ran EXTREMELY FAST :clap:
Have you ever vacuumed the DB?
--
Alvaro Herrera
with the filesystem features, at which point I shut up
or they shut me down.
--
Alvaro Herrerahttp://www.CommandPrompt.com/
The PostgreSQL Company - Command Prompt, Inc.
---(end of broadcast)---
TIP 5: don't forget to increase
the EXPLAIN ANALYZE again.
It would be extremely helpful if you saved it in a file and attached it
separately so that the indentation and whitespace is not mangled by your
email system. It would be a lot more readable that way.
--
Alvaro Herrerahttp
.
--
Alvaro Herrerahttp://www.CommandPrompt.com/
The PostgreSQL Company - Command Prompt, Inc.
---(end of broadcast)---
TIP 4: Have you searched our list archives?
http://archives.postgresql.org
wraparound.
--
Alvaro Herrera http://www.flickr.com/photos/alvherre/
La soledad es compañía
---(end of broadcast)---
TIP 4: Have you searched our list archives?
http://archives.postgresql.org
, that
is.
--
Alvaro Herrera http://www.amazon.com/gp/registry/5ZYLFMCVHXC
The only difference is that Saddam would kill you on private, where the
Americans will kill you in public (Mohammad Saleh, 39, a building contractor)
---(end of broadcast
you should be looking at is whether you can forget vacuuming
the whole database in one go, and make it more granular.
--
Alvaro Herrera http://www.flickr.com/photos/alvherre/
Having your biases confirmed independently is how scientific progress is
made, and hence made our
Karl Wright wrote:
Alvaro Herrera wrote:
Karl Wright wrote:
(b) the performance of individual queries had already degraded
significantly in the same manner as what I'd seen before.
You didn't answer whether you had smaller, more frequently updated
tables that need more vacuuming
Karl Wright wrote:
Alvaro Herrera wrote:
Karl Wright wrote:
I am afraid that I did answer this. My largest tables are the ones
continually being updated. The smaller ones are updated only
infrequently.
Can you afford to vacuum them in parallel?
Hmm, interesting question. If VACUUM
all the time? If so,
that's where the problem lies.
--
Alvaro Herrera http://www.amazon.com/gp/registry/CTMLCN8V17R4
Cómo ponemos nuestros dedos en la arcilla del otro. Eso es la amistad; jugar
al alfarero y ver qué formas se pueden sacar del otro (C. Halloway en
La Feria de las
Karl Wright wrote:
Alvaro Herrera wrote:
Karl Wright wrote:
This particular run lasted four days before a VACUUM became essential.
The symptom that indicates that VACUUM is needed seems to be that the
CPU usage of any given postgresql query skyrockets. Is this essentially
correct
increasing it, with ALTER TABLE ... SET STATISTICS, rerun analyze, and
try again.
--
Alvaro Herrerahttp://www.CommandPrompt.com/
The PostgreSQL Company - Command Prompt, Inc.
---(end of broadcast)---
TIP 7: You can help
of table alvherre.public.foo: index scans: 0
pages: 45 removed, 0 remain
tuples: 1 removed, 0 remain
system usage: CPU 0.00s/0.00u sec elapsed 0.01 sec
LOG: automatic analyze of table alvherre.public.foo system usage: CPU
0.00s/0.00u sec elapsed 0.00 sec
--
Alvaro Herrera
if
you want it to interfere less with your regular operation.
--
Alvaro Herrerahttp://www.CommandPrompt.com/
The PostgreSQL Company - Command Prompt, Inc.
---(end of broadcast)---
TIP 3: Have you checked our extensive FAQ
if autovacuum is eating all your I/O you may want to look into
throttling it back a bit by setting autovacuum_vacuum_cost_delay to a
non-zero value.
--
Alvaro Herrerahttp://www.advogato.org/person/alvherre
La tristeza es un muro entre dos jardines (Khalil Gibran
, *within* a single large transaction :-( Yeah that's probably not
very solvable for the moment.
--
Alvaro Herrera Valdivia, Chile ICBM: S 39º 49' 18.1, W 73º 13' 56.4
Ninguna manada de bestias tiene una voz tan horrible como la humana (Orual)
---(end of broadcast
Tom Lane wrote:
Alvaro Herrera [EMAIL PROTECTED] writes:
Also if autovacuum is eating all your I/O you may want to look into
throttling it back a bit by setting autovacuum_vacuum_cost_delay to a
non-zero value.
BTW, why is it that autovacuum_cost_delay isn't enabled by default?
I can
at the eliminatecc
option in the Majordomo user web pages.
--
Alvaro Herrerahttp://www.CommandPrompt.com/
The PostgreSQL Company - Command Prompt, Inc.
---(end of broadcast)---
TIP 7: You can help support the PostgreSQL project
.
--
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 racer developers.
(Scott Marlowe)
---(end of broadcast
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.com
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 vacuuming the tables?
--
Alvaro Herrerahttp
.
--
Alvaro Herrera http://www.flickr.com/photos/alvherre/
Puedes vivir solo una vez, pero si lo haces bien, una vez es suficiente
---(end of broadcast)---
TIP 2: Don't 'kill -9' the postmaster
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 default.
--
Alvaro Herrerahttp
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.
--
Alvaro Herrera
faster
workaround.
--
Alvaro Herrerahttp://www.CommandPrompt.com/
The PostgreSQL Company - Command Prompt, Inc.
---(end of broadcast)---
TIP 4: Have you searched our list archives?
http
supposedly be faster.
--
Alvaro Herrerahttp://www.CommandPrompt.com/
PostgreSQL Replication, Consulting, Custom Development, 24x7 support
---(end of broadcast)---
TIP 2: Don't 'kill -9' the postmaster
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/
The PostgreSQL Company - Command Prompt, Inc
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 Herrerahttp
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 have. Ability to set per-table configuration
for example.
--
Alvaro Herrerahttp
). 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.CommandPrompt.com/
PostgreSQL
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 - Command Prompt, Inc.
---(end of broadcast
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
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, the planner
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
times a day. I have tried looking for what
the triggers insert deltas records; to
get the sum, add them all. Periodically, take the deltas and apply them
to the totals.
--
Alvaro Herrerahttp://www.CommandPrompt.com/
PostgreSQL Replication, Consulting, Custom Development, 24x7 support
---(end
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)---
TIP 2: Don't 'kill -9
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 Herrerahttp://www.CommandPrompt.com
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 different table?
No, no problem. Keep in mind that if one
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 - Command Prompt, Inc
'enable_%';
--
Alvaro Herrerahttp://www.CommandPrompt.com/
The PostgreSQL Company - Command Prompt, Inc.
---(end of broadcast)---
TIP 4: Have you searched our list archives?
http://archives.postgresql.org
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, Inc.
---(end of broadcast
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, 24x7 support
.
--
Alvaro Herrerahttp://www.CommandPrompt.com/
The PostgreSQL Company - Command Prompt, Inc.
---(end of broadcast)---
TIP 3: Have you checked our extensive FAQ?
http://www.postgresql.org/docs/faq
://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 Development, 24x7 support
---(end of broadcast
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.
(
I set the following, as well as the option to enable auto
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
--
Alvaro Herrera
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? Having a recheck would be redundant.
--
Alvaro Herrerahttp://www.CommandPrompt.com/
The PostgreSQL Company - Command Prompt, Inc
preventing that in 8.2?
--
Alvaro Herrerahttp://www.CommandPrompt.com/
PostgreSQL Replication, Consulting, Custom Development, 24x7 support
---(end of broadcast)---
TIP 1: if posting/reading through Usenet, please send
is more impressive in
PHB terms.
--
Alvaro Herrerahttp://www.CommandPrompt.com/
PostgreSQL Replication, Consulting, Custom Development, 24x7 support
---(end of broadcast)---
TIP 9: In versions below 8.0, the planner
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 hard to come up with distributions where
it's
1000x as fast and others where
201 - 300 of 426 matches
Mail list logo
