On 30.4.2015 19:08, Jonathan Vanasco wrote:
On Apr 29, 2015, at 6:50 PM, Jim Nasby wrote:
Only because you're using UNION. Use UNION ALL instead.
The difference between union and union all was negligible. the problem
was
in the subselect and the sheer size of the tables, even when we
On Apr 29, 2015, at 6:50 PM, Jim Nasby wrote:
Only because you're using UNION. Use UNION ALL instead.
The difference between union and union all was negligible. the problem was
in the subselect and the sheer size of the tables, even when we could handle it
as an index-only scan.
On Apr
Hello.
On 29.4.2015 01:57, Jonathan Vanasco wrote:
Sorry, I was trying to ask something very abstract as I have similar
situations
on multiple groups of queries/tables (and they're all much more complex).
I'm on pg 9.3
The relevant structure is:
posting:
id
Hello.
On 29.4.2015 00:26, Jonathan Vanasco wrote:
I'm trying to upgrade some code that powers a newfeed type stream, and hoping
someone can offer some insight on better ways to structure some parts of the
query
The part that has me stumped right now...
There are several criteria
On Apr 29, 2015, at 12:25 PM, Ladislav Lenart wrote:
Could you please explain to me the error(s) in my reasoning?
Let me just flip your list in reverse... and add in some elements (marked with
a *):
posting ts context
p60 60 friend
p55 55 friend*
p54 54 friend*
p50 50
Hello.
On 29.4.2015 17:27, Jonathan Vanasco wrote:
Thanks all! These point me in much better directions!
Jim Nasby's approach to selecting an expression addressed some things (SELECT
f.useraccount_id_b IS NOT NULL AS in_friends)
Ladislav Lenart's usage of the CTE is also of a
On 29.4.2015 18:54, Jonathan Vanasco wrote:
On Apr 29, 2015, at 12:25 PM, Ladislav Lenart wrote:
Could you please explain to me the error(s) in my reasoning?
Let me just flip your list in reverse... and add in some elements (marked
with a *):
posting ts context
p60 60 friend
On 4/29/15 11:54 AM, Jonathan Vanasco wrote:
IIRC, the best mix of performance and product that I've found is do something
like this:
SELECT * FROM (
SELECT a,b,c FROM table_a ORDER BY TIMESTAMP DESC LIMIT 1;
UNION
SELECT a,b,c FROM
I see others have responded with suggestions to improve query performance,
but one thing I noticed when you gave the data structure is there are no
no primary keys defined for friends or posting, neither are there any
indexes.
Was that an omission? If not, then please note that PostgreSQL is a
Thanks all! These point me in much better directions!
Jim Nasby's approach to selecting an expression addressed some things (SELECT
f.useraccount_id_b IS NOT NULL AS in_friends)
Ladislav Lenart's usage of the CTE is also of a different format that I've used
in the past.
I think i'll be able
Sorry, I was trying to ask something very abstract as I have similar situations
on multiple groups of queries/tables (and they're all much more complex).
I'm on pg 9.3
The relevant structure is:
posting:
id
timestamp_publish
group_id__in
user_id__author
Since you very nicely DID NOT provide the pg version, O/S or table
structure(s), which is what you should do REGARDLESS of the
type of question (it's just the smart and polite thing to do when asking
for help) The best I can suggest is:
SELECT
CASE WHEN context = 'friend' THEN p.junka
On 4/28/15 6:57 PM, Jonathan Vanasco wrote:
The relevant structure is:
posting:
id
timestamp_publish
group_id__in
user_id__author
friends:
user_id__a
user_id__b
memberships:
user_id
group_id
role_id
I'm trying to upgrade some code that powers a newfeed type stream, and hoping
someone can offer some insight on better ways to structure some parts of the
query
The part that has me stumped right now...
There are several criteria for why something could appear in a stream. for
example, here
14 matches
Mail list logo
