Magnus Hagander wrote:
> > > I'm hoping someone can shed some light on these results.
> >
> > Not without a lot more detail on how you *got* the results.
> > What exactly did you do to force the various plan choices?
> > (I see some ridiculous choices of indexscans, for instance,
> > suggesti
Tom Lane wrote:
What exactly did you do to force the various plan choices? (I see some
ridiculous choices of indexscans, for instance, suggesting improper use
of enable_seqscan in some cases.)
Except for forcing a hash with indexes (to show that increased use of
indexes is not necessarily good),
On Thu, 3 Feb 2005, Tom Lane wrote:
"Marinos J. Yannikos" <[EMAIL PROTECTED]> writes:
I can't seem to find out where the bottleneck is, but it doesn't seem to
be CPU or disk. "top" shows that postgres processes are frequently in
this state:
6701 postgres 16 0 204m 58m 56m S 9.3 0.2 0:0
Tom Lane schrieb:
What's the platform exactly (hardware and OS)?
Hardware: http://www.appro.com/product/server_1142h.asp
- SCSI version, 2 x 146GB 10k rpm disks in software RAID-1
- 32GB RAM
OS: Linux 2.6.10-rc3, x86_64, debian GNU/Linux distribution
- CONFIG_K8_NUMA is currently turned off (no cha
Magnus wrote:
> > > I'm hoping someone can shed some light on these results.
> >
> > Not without a lot more detail on how you *got* the results.
> > What exactly did you do to force the various plan choices?
> > (I see some ridiculous choices of indexscans, for instance,
> > suggesting improper use
> > I'm hoping someone can shed some light on these results.
>
> Not without a lot more detail on how you *got* the results.
> What exactly did you do to force the various plan choices?
> (I see some ridiculous choices of indexscans, for instance,
> suggesting improper use of enable_seqscan i
"Marinos J. Yannikos" <[EMAIL PROTECTED]> writes:
> I can't seem to find out where the bottleneck is, but it doesn't seem to
> be CPU or disk. "top" shows that postgres processes are frequently in
> this state:
> 6701 postgres 16 0 204m 58m 56m S 9.3 0.2 0:06.96 semtimedo
>
David Brown <[EMAIL PROTECTED]> writes:
> I'm hoping someone can shed some light on these results.
Not without a lot more detail on how you *got* the results. What
exactly did you do to force the various plan choices? (I see some
ridiculous choices of indexscans, for instance, suggesting imprope
I'll repeat myself:
Please CC the mailing list as well as replying to me, so that others
can help too.
Din Adrian wrote:
On Thu, 03 Feb 2005 13:56:50 +, Richard Huxton
wrote:
Please CC the mailing list as well as replying to me, so that others
can help too.
b) in docs say that after
Please CC the mailing list as well as replying to me, so that others can
help too.
Din Adrian wrote:
yes I have read this as well ...
One question about this option:
fsync = true / false
a) I have Raid and UPS - it is safe to turn this off ... (' But be
very aware that any unexpected database
Hi, all,
Markus Schaber schrieb:
> As a small workaround, I could imagine to add a small additional column
> in the table that contains the geometry's bbox, and which I use the &&
> operator against. This should avoid touching the TOAST for the skipped rows.
For your personal amusement: I just n
Oleg Bartunov wrote:
Marinos,
what if you construct "apachebench & Co" free script and see if
the issue still exists. There are could be many issues doesn't
connected to postgresql and tsearch2.
Yes, the problem persists - I wrote a small perl script that forks 10
chils processes and executes the
Marinos,
what if you construct "apachebench & Co" free script and see if
the issue still exists. There are could be many issues doesn't
connected to postgresql and tsearch2.
Oleg
On Thu, 3 Feb 2005, Marinos J. Yannikos wrote:
Oleg Bartunov wrote:
On Thu, 3 Feb 2005, Marinos J. Yannikos wrote:
conc
Do you have anything performing any updates or inserts to this table,
even if it does not update the gist column, even if it does not update
anything ?
---(end of broadcast)---
TIP 6: Have you searched our list archives?
http://arc
I'm hoping someone can shed some light on these results. The 'factor'
compares the ratios of cost to actual for different plans. Perhaps
nested loops should be given a discount in the planner? The estimates
seem to be out by one and a half orders of magnitude. :(
== QUERY ==
SEL
Oleg Bartunov wrote:
On Thu, 3 Feb 2005, Marinos J. Yannikos wrote:
concurrent access to GiST indexes isn't possible at the moment. I [...]
there are should no problem with READ access.
OK, thanks everyone (perhaps it would make sense to clarify this in the
manual).
I'm willing to see some detail
Din Adrian wrote:
Hello,
I have a little time and I decided to improve the performance of my
server(s). I have found on google many 'tips' in tuning linux kernel
and postgresql database ... but I can't decide wich 'how-to' is better
... :(
So the question is: where to find a 'easy' and complet
Josh Berkus wrote:
Gaetano,
I did in that way just to not use postgresql specific feature.
I can give it a try and I let you know, however the question remain,
why the index usage is lost if used in that way ?
Because PostgreSQL is materializing the entire UNION data set in the
subselect. What
Hi, Tom,
Tom Lane schrieb:
> What I would be inclined to do is to extend ANALYZE to make an estimate
> of the extent of toasting of every toastable column, and then modify
> cost_qual_eval to charge a nonzero cost for evaluation of Vars that are
> potentially toasted.
I currently do not have any
On Thu, 3 Feb 2005, Marinos J. Yannikos wrote:
Hi,
according to http://www.postgresql.org/docs/8.0/interactive/limitations.html
, concurrent access to GiST indexes isn't possible at the moment. I haven't
read the thesis mentioned there, but I presume that concurrent read access is
also impossibl
Hello,
I have a little time and I decided to improve the performance of my
server(s). I have found on google many 'tips' in tuning linux kernel and
postgresql database ... but I can't decide wich 'how-to' is better ... :(
So the question is: where to find a 'easy' and complete documentation
a
It seems to be a big problem with tsearch2, when multiple clients are
hammering the db (we have a quad opteron box here that stays 75% idle
despite an apachebench with concurrency 10 stressing the php script that
uses tsearch2, with practically no disk accesses)
Concurrency with READs is fine -
On Wed, Feb 02, 2005 at 06:02:28PM +0800, Hasnul Fadhly bin Hasan wrote:
> When new data is inserted, we have to use new. to access the data.
> Is there another way to access the data that would be more generic
> like value[1] and so on? This way, the tracker is independant of any
> tables
23 matches
Mail list logo
