On 10/10/06, Jim C. Nasby <[EMAIL PROTECTED]> wrote:
> >Try w/o the explain analyze. It adds quite a bit of overhead and that
> >might be inconsistant between the systems (mainly it may have to do with
> >the gettimeofday() calls being implemented differently between Windows
> >and Linux..).
>
>
> 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.
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 t
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 inde
"Jim C. Nasby" <[EMAIL PROTECTED]> writes:
> 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 wit
>
> 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
>
"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
> im
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 t
[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 acc
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 relp
On Mon, Oct 09, 2006 at 02:41:07PM -0400, Merlin Moncure wrote:
> 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_se
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
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
[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 oth
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/
--
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.
* 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 inc
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 3700+
Josh Berkus 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 broadcast)---
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
> discussio
> 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
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 synt
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
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 for a table to be updated after
autovacuum ran.
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 (yo
25 matches
Mail list logo
