Dear all,
I have a query on 3 tables in a database as :-
_*Explain Analyze Output :-*_
explain anayze select c.clause, s.subject ,s.object , s.verb,
s.subject_type , s.object_type ,s.doc_id ,s.svo_id from clause2 c, svo2
s ,page_content p where c.clause_id=s.clause_id and s.doc_id=c.source_id
On 2011-05-16 06:41, Jesper Krogh wrote:
On 2011-05-16 03:18, Greg Smith wrote:
You can't do it in real-time. You don't necessarily want that to
even if it were possible; too many possibilities for nasty feedback
loops where you always favor using some marginal index that happens
to be in me
On 2011-05-16 03:18, Greg Smith wrote:
You can't do it in real-time. You don't necessarily want that to
even if it were possible; too many possibilities for nasty feedback
loops where you always favor using some marginal index that happens
to be in memory, and therefore never page in things t
Craig Ringer wrote:
AFAIK, mincore() is only useful for mmap()ed files and for finding out
if it's safe to access certain blocks of memory w/o risking triggering
heavy swapping.
It doesn't provide any visibility into the OS's block device / file
system caches; you can't ask it "how much of this
On 16/05/11 05:45, Cédric Villemain wrote:
> 2011/5/15 Josh Berkus :
>> disk pages might be in cache.
>> However, I think that's beyond feasibility for current software/OSes.
>
> maybe not :) mincore is available in many OSes, and windows have
> options to get those stats too.
AFAIK, mincore() is
On 14/05/11 18:10, Stefan Keller wrote:
> Hi,
>
> I am conducting a benchmark to compare KVP table vs. hstore and got
> bad hstore performance results when the no. of records is greater than
> about 500'000.
>
> CREATE TABLE kvp ( id SERIAL PRIMARY KEY, key text NOT NULL, value text );
> -- with
Try wrapping all your inserts in a transaction:
pg_query('BEGIN');
// your inserts
pg_query('COMMIT');
That way you won't have to sync each of those inserts to disk, should
provide a huge speedup. Of course this means your 10,000 inserts will be
all or nothing, but it seems like in this case tha
Hi, I'm new to postgres and I have the next question.
I have a
php program that makes 10 inserts in my database.
autoincrement
numbers inserted into a table with 5 columns.
The script takes about 4
minutes from a webserver
Is it a normal time?
How could reduce this
time by a bulce of
2011/5/15 Josh Berkus :
> Stuart,
>
>> I think random_page_cost causes problems because I need to combine
>> disk random access time, which I can measure, with a guesstimate of
>> the disk cache hit rate.
>
> See, that's wrong. Disk cache hit rate is what effective_cache_size
> (ECS) is for.
>
> Re
On Thu, May 12, 2011 at 3:18 AM, Sethu Prasad wrote:
> http://sourceforge.net/mailarchive/forum.php?forum_name=osdldbt-general&max_rows=25&style=nested&viewmonth=201104
It's not very obvious from reading through that link what you still
need help with.
http://wiki.postgresql.org/wiki/Guide_to_re
On Tue, May 10, 2011 at 3:23 AM, Sethu Prasad wrote:
> Yes it has something to do with Hot Standby, if you omit some parts on the
> archive then the standby instance will not have the necessary stuff and
> complain like this..
If you omit some parts of the archive, it won't start at all. To get
On Sun, May 15, 2011 at 2:08 PM, Josh Berkus wrote:
>> All true. I suspect that in practice the different between random and
>> sequential memory page costs is small enough to be ignorable, although
>> of course I might be wrong.
>
> This hasn't been my experience, although I have not carefully m
Stuart,
> I think random_page_cost causes problems because I need to combine
> disk random access time, which I can measure, with a guesstimate of
> the disk cache hit rate.
See, that's wrong. Disk cache hit rate is what effective_cache_size
(ECS) is for.
Really, there's several factors which sh
Robert,
> All true. I suspect that in practice the different between random and
> sequential memory page costs is small enough to be ignorable, although
> of course I might be wrong.
This hasn't been my experience, although I have not carefully measured
it. In fact, there's good reason to sup
14 matches
Mail list logo