On 10/6/06, Carlo Stonebanks [EMAIL PROTECTED] wrote:
how did you determine that it is done every 500 rows? this is the
The import program pages the import table - it is currently set at 500 rows
per page. With each page, I run an ANALYZE.
right, i just wanted to make sure of something (you
Ive recently moved to 8.1 and find that autovacuum
doesnt seem to be working, at least not the way I expected it to. I
need the tuple count for a table to be updated so indexes will be used when
appropriate. I was expecting the tuples count for a table to be updated after
autovacuum ran.
In response to Medora Schauer [EMAIL PROTECTED]:
I've recently moved to 8.1 and find that autovacuum doesn't seem to be
working, at least not the way I expected it to. I need the tuple count
for a table to be updated so indexes will be used when appropriate. I
was expecting the tuples count
On 10/8/06, Jim C. Nasby [EMAIL PROTECTED] wrote:
On Thu, Oct 05, 2006 at 09:30:45AM -0400, Merlin Moncure wrote:
I personally only use explicit joins when doing outer joins and even
them push them out as far as possible.
I used to be like that too, until I actually started using join syntax.
From: Bill Moran [mailto:[EMAIL PROTECTED]
In response to Medora Schauer [EMAIL PROTECTED]:
I've recently moved to 8.1 and find that autovacuum doesn't seem to
be
working, at least not the way I expected it to. I need the tuple
count
for a table to be updated so indexes will be used
Tom,
Josh's post points out some reasons why it's not that easy to get
long-term benefits from hints --- you could possibly address some of
those problems, but a hint language that responds to those criticisms
won't be trivial to design, implement, or maintain. See (many) past
discussions
Josh Berkus josh@agliodbs.com writes:
Unfortunately, EDB's solution is likely to be Oracle-based, which is
liable to fall into the trap of not good enough.
I'd be a bit worried about Oracle patents as well...
regards, tom lane
---(end of
I have two systems running 8.2beta1 getting strange difference of
results in count(*). Query that illistrates the difference is
count(*). this is a synthetic test i use to measure a sytems's cpu
performance.
System A:
2.2 ghz p4 northwood, HT
win xp
vanilla sata (1 disk)
System B:
amd 64
* Merlin Moncure ([EMAIL PROTECTED]) wrote:
explain analyze select 5000!;
A: 2.4 seconds
B: 1.8 seconds
explain analyze select count(*) from generate_series(1,50);
A: 0.85 seconds
B: 4.94 seconds
Try w/o the explain analyze. It adds quite a bit of overhead and that
might be
On 10/9/06, Stephen Frost [EMAIL PROTECTED] wrote:
* Merlin Moncure ([EMAIL PROTECTED]) wrote:
explain analyze select 5000!;
A: 2.4 seconds
B: 1.8 seconds
explain analyze select count(*) from generate_series(1,50);
A: 0.85 seconds
B: 4.94 seconds
Try w/o the explain analyze. It adds
On Mon, Oct 09, 2006 at 02:41:07PM -0400, Merlin Moncure wrote:
that was it. amd system now drop to .3 seconds, windows .6. (doing
time foo psql -c bar file). thanks...
What you want is probably \timing in psql, by the way. :-)
/* Steinar */
--
Homepage: http://www.sesse.net/
[EMAIL PROTECTED] (Craig A. James) writes:
Mark Kirkwood wrote:
The result? I can't use my function in any WHERE clause that
involves any other conditions or joins. Only by itself. PG will
occasionally decide to use my function as a filter instead of doing
the join or the other WHERE
On Sun, 2006-10-08 at 18:05, Josh Berkus wrote:
Now, if you were offering us a patch to auto-populate the statistics as a
table is loaded, I'd be all for that. But I, personally, would need a
lot of convincing to believe that hints don't do more harm than good.
Actually, I'd much rather
On Mon, Oct 09, 2006 at 06:07:29PM +, Chris Browne wrote:
[EMAIL PROTECTED] (Craig A. James) writes:
Mark Kirkwood wrote:
The result? I can't use my function in any WHERE clause that
involves any other conditions or joins. Only by itself. PG will
occasionally decide to use my
On Mon, Oct 09, 2006 at 09:27:30AM -0500, Medora Schauer wrote:
From your attached config file:
#autovacuum_vacuum_threshold = 1000 # min # of tuple updates before
# vacuum
Yup, that was it.
Actually, not quite.
Vacuum will update relpages and
[Jim C. Nasby - Mon at 04:18:27PM -0500]
I can agree to that, but we'll never get any progress so long as every
time hints are brought up the response is that they're evil and should
never be in the database. I'll also say that a very simple hinting
language (ie: allowing you to specify access
On Mon, Oct 09, 2006 at 11:33:03PM +0200, Tobias Brox wrote:
[Jim C. Nasby - Mon at 04:18:27PM -0500]
I can agree to that, but we'll never get any progress so long as every
time hints are brought up the response is that they're evil and should
never be in the database. I'll also say that a
Jim C. Nasby [EMAIL PROTECTED] writes:
I'll also say that a very simple hinting
language (ie: allowing you to specify access method for a table, and
join methods) would go a huge way towards enabling app developers to get
stuff done now while waiting for all these magical optimizer
One of the big problems with doing set enable_...=off is that there's no
way to embed that into something like a view, so you're almost forced
into putting into the application code itself, which makes matters even
worse. If you could hint this within a query (maybe even on a per-table
PG does support hints actually.. and I used them to solve the last performance
problem I had, rather than waiting n years for the query planner to be
improved. The problem in question (from an automated query planning point of
view) is the lack of multi-column statistics, leading to the wrong
Brian Herlihy wrote:
PG does support hints actually..
The only thing is, the hints are expressed in an obscure, ad-hoc and
implementation dependant language.
For example, the Don't use index X hint (the one I used) can be accessed by
replacing your index with an index on values derived from
Imagine I got run over by a train, and someone was reading my code.
Which would be easier for them to maintain: Code with weird SQL, or code
with sensible, well-written SQL and explicit hints?
You forgot the most important option:
Code with appropriate documentation about your weird SQL.
22 matches
Mail list logo
