Thanks for the response.
I've taken a look at this feature. But it seems unapplicable to my case:
this table is not a many2many relation which seems the most common case
of the intarray usage.
The table just stores an information about items (rss posts): what feeds
(rss) are they from, and thei
Hello everybody!
I have found a performance issue with 2 equivalent queries stably
taking different (~x2) time to finish. In just a few words it can be
described like this: if you have a lot of values in an IN() statement,
you should put most heavy (specifying most number of rows) ids first.
T
You may try contrib/intarray, which we developed specially for
denormalization.
Oleg
On Thu, 29 May 2008, Alexey Kupershtokh wrote:
Hello everybody!
I have found a performance issue with 2 equivalent queries stably taking
different (~x2) time to finish. In just a few words it can be described
On Wed, 2008-05-28 at 16:59 -0700, Josh Berkus wrote:
> Folks,
> shared_buffers: according to witnesses, Greg Smith presented at East that
> based on PostgreSQL's buffer algorithms, buffers above 2GB would not
> really receive significant use. However, Jignesh Shah has tested that on
> work
[Attn list-queue maintainers: Please drop the earlier version
of this email that I accidentally sent from an unsubscribed address. ]
Hi,
I'm having a strange problem with a slow-running select query. The
query I use in production ends in "LIMIT 1", and it runs very slowly.
But when I remove the
Chris Shoemaker wrote:
[Attn list-queue maintainers: Please drop the earlier version
of this email that I accidentally sent from an unsubscribed address. ]
Hi,
I'm having a strange problem with a slow-running select query. The
query I use in production ends in "LIMIT 1", and it runs very slo
I'm doing some analysis on temporal usages, and was hoping to make use
of OVERLAPS, but it does not appear that it makes use of indices.
Couching this in an example... I created a table, t1, thus:
metadata=# \d t1
Table "public.t1"
Column | Type
On Fri, May 30, 2008 at 02:23:46AM +0930, Shane Ambler wrote:
> Chris Shoemaker wrote:
>> [Attn list-queue maintainers: Please drop the earlier version
>> of this email that I accidentally sent from an unsubscribed address. ]
>>
>> Hi,
>> I'm having a strange problem with a slow-running select que
Chris Shoemaker <[EMAIL PROTECTED]> writes:
> Still stumped,
The short answer here is that the planner is guessing that scanning the
index in ID order will come across the desired row (ie, the first one
matching the join condition) in less time than it will take to select
all the joinable rows, so
Joshua D. Drake wrote:
>
>
> On Wed, 2008-05-28 at 16:59 -0700, Josh Berkus wrote:
> > Folks,
>
> > shared_buffers: according to witnesses, Greg Smith presented at
> > East that based on PostgreSQL's buffer algorithms, buffers above
> > 2GB would not really receive significant use. However, Ji
Based on feedback after the sessions I did few more tests which might be
useful to share
One point that was suggested to get each clients do more work and reduce
the number of clients.. The igen benchmarks was flexible and what I did
was remove all think time from it and repeated the test till
"Jignesh K. Shah" <[EMAIL PROTECTED]> writes:
> Note with this no think time concept, each clients can be about 75% CPU busy
> from what I observed. running it I found the clients scaling up saturates at
> about 60 now (compared to 500 from the original test). The peak throughput
> was
> at abou
12 matches
Mail list logo
