Phoenix Kiula writes:
> Index Cond: ((user_id)::text = 'superman'::text)
> Filter: (status = 'Y'::bpchar)
> Of course for unregistered users we use user_known = 0, so they are
> excluded from this index. Is this not a useful partial index? I think
> in t
On Jan 29, 2009, at 1:35 AM, Phoenix Kiula wrote:
On Thu, Jan 29, 2009 at 2:25 AM, Alban Hertroys
wrote:
Ah I see, that's the original query and its plan again, not the one
after
implementing those triggers! You had me scratching my head for a
bit there,
wondering why the count() subquery
On Thu, Jan 29, 2009 at 2:25 AM, Alban Hertroys
wrote:
> Ah I see, that's the original query and its plan again, not the one after
> implementing those triggers! You had me scratching my head for a bit there,
> wondering why the count() subquery was still there.
Yes that was just for info. He
On Jan 28, 2009, at 1:38 PM, Phoenix Kiula wrote:
Thanks Alban. We have now made all the triggers and such. That part is
working. I suppose not having the count(id) is helping just with a few
seconds, but the query is still taking about 15 seconds in some cases.
Here are the query and its exec
On Wed, Jan 28, 2009 at 2:37 AM, Alban Hertroys
wrote:
>
> Does that query plan look any better without the select count(id) from
> testimonials?
>
> If so you may be better off keeping track of those counts in a separate
> table updated by triggers on the testimonials table. Whether that really
>
On Jan 26, 2009, at 4:41 AM, Phoenix Kiula wrote:
Appreciate any thoughts.
My query is:
explain analyze SELECT
testimonials.url
,testimonials.alias
,testimonials.aliasEntered
,testimonials.title
,testimonials.modify_date
,testi
On Mon, Jan 26, 2009 at 12:06 AM, Phoenix Kiula wrote:
> On Mon, Jan 26, 2009 at 3:04 PM, Scott Marlowe
> wrote:
>> On Sun, Jan 25, 2009 at 11:58 PM, Phoenix Kiula
>> wrote:
>>> Hi Scott. Yes, there is an autovacuum on both the tables. Should i
>>> additionally do a manual vacuum too?
>>
>> Na
On Mon, Jan 26, 2009 at 3:04 PM, Scott Marlowe wrote:
> On Sun, Jan 25, 2009 at 11:58 PM, Phoenix Kiula
> wrote:
>> Hi Scott. Yes, there is an autovacuum on both the tables. Should i
>> additionally do a manual vacuum too?
>
> Nah, just an analyze. what version of pgsql is this, btw?
>
Actual
On Sun, Jan 25, 2009 at 11:58 PM, Phoenix Kiula wrote:
> Hi Scott. Yes, there is an autovacuum on both the tables. Should i
> additionally do a manual vacuum too?
Nah, just an analyze. what version of pgsql is this, btw?
--
Sent via pgsql-general mailing list (pgsql-general@postgresql.org)
To
On Mon, Jan 26, 2009 at 2:26 PM, Scott Marlowe wrote:
> On Sun, Jan 25, 2009 at 8:41 PM, Phoenix Kiula
> wrote:
>
>> My query is:
>>
>>
>> explain analyze SELECT
>>testimonials.url
>>,testimonials.alias
>>,testimonials.aliasEntered
>>,testimonials.
On Sun, Jan 25, 2009 at 8:41 PM, Phoenix Kiula wrote:
> My query is:
>
>
> explain analyze SELECT
>testimonials.url
>,testimonials.alias
>,testimonials.aliasEntered
>,testimonials.title
>,testimonials.modify_date
>,testimonia
Hope someone can shed light on this.
I have a well-performing query that uses the index. Without OFFSET etc
it returns about 11,000 records.
I only need about 20 of these records at any given time, which is why
my LIMIT and OFFSET try to pull only the 20 records or so.
My queries are fast in gen
12 matches
Mail list logo
