Kashmira Patel wrote:
> I did do an EXPLAIN ANALYZE as well, it also showed a
> sequential scan. The table has about 600+ rows, with around 6 of them
> matching the given id. Wouldn't an index scan be faster in this case?
Not necessarily. It's entirely possible, if your rows are small, that 600
This is how I created the index:
CREATE INDEX msgid_index ON vm_message(msgid);
I guess it doing this because its a small table then. I will try putting
more values.
Thanks,
Kashmira
-Original Message-
From: [EMAIL PROTECTED]
[mailto:[EMAIL PROTECTED] On Behalf Of Andrew Sullivan
Sent
On Thu, Feb 23, 2006 at 02:25:34PM -0800, Kashmira Patel (kupatel) wrote:
>
> [Kashmira] I did do an EXPLAIN ANALYZE as well, it also showed a
> sequential scan. The table has about 600+ rows, with around 6 of them
> matching the given id. Wouldn't an index scan be faster in this case?
EXPLAIN AN
The index has been around since I first created the table. I did VACUUM
ANALYZE, that should have taken care of analyzing this table, right?
-Original Message-
From: Tomas Vondra [mailto:[EMAIL PROTECTED]
Sent: Thursday, February 23, 2006 2:29 PM
To: Kashmira Patel (kupatel)
Subject: Re:
> For example: I have a table vm_message with an index on column msgid.
> Will the following do a sequential scan or an index?
>
> select count(*) from vm_message where msgid = 3;
How much of the table is that? How many rows? EXPLAIN ANALYSE will
tell you if you have the right plan (estimate
On Thu, Feb 23, 2006 at 01:44:43PM -0800, Kashmira Patel (kupatel) wrote:
> My understanding of this statement is that if I use count() without a
> WHERE clause, then essentially, it is applied to the entire table and
> hence requires a seq scan.
> But it should not require a seq scan if I have a c
Hello,
I am
using postgres version 7.4, and I read this in the
documentation:
"The aggregate
functions sum and count always require a sequential scan if applied to the
entire table."
My understanding of
this statement is that if I use count() without a WHERE clause, then
essentially
On Thu, 2006-02-23 at 17:35 +0100, PFC wrote:
>
> > Now, If some other user want's his prize, when checking his code, if he
> > sends code for some other service then service 1, that's ok. If he's
> > sends code for the service 1 the PERFORM will wait untill I'm finished
> > with previous user.
>
Hi Jim, Thanks for the tip, It worked!Thanks a lot!!!Daniel Hernández.Tijuana, BC, México."More you learn, more you earn".try select ...,sum(case when sales.itemname = 'some' then sales.count else 0 end) as "Sales Candies"from your_table_heregroup by ...<[EMAIL PROTECTED]>Join Excite! - htt
try
select ...,sum(case when sales.itemname = 'some' then sales.count else 0 end)
as "Sales Candies"
from your_table_here
group by ...
-- Original Message ---
From: "Daniel Hernandez" <[EMAIL PROTECTED]>
To: pgsql-sql@postgresql.org
Sent: Thu, 23 Feb 2006 12:46:44 -0500 (EST)
Hi Guys, I'm new on this group, and I have a question, is there a way to do a "sum if" (kind of)?What i want to do is the following.Select customers.custid, if (sales.itemname = 'candy', sum(sales.count)) as "Sales candies", if (sales.itemname = 'some', sum(sales.count)) as "Sales Some"from ...j
Now, If some other user want's his prize, when checking his code, if he
sends code for some other service then service 1, that's ok. If he's
sends code for the service 1 the PERFORM will wait untill I'm finished
with previous user.
Sorry for the double post.
If the rows in your tabl
I lock just that particular row, which is no good. I need to have all
the codes for the service 1 locked, so if it happens that two users send
the very same code, one has to fail. Therefore, from within plpgsql I
first do:
I'm a bit tired tonight so I'll simplify your example :
CREAT
On Thu, 2006-02-23 at 13:56 +0200, Achilleus Mantzios wrote:
> The intersection of rows that satisfy BOTH
> "code_id = 1 AND code_value = 'abla'"
> and
> "code_id = 1 AND code_value = 'eble'"
> is ZERO!!!
>
> Why would you want irrelevant rows to wait for one another??
It was a bit silly repre
On Wed, 2006-02-22 at 13:58 -0500, Tom Lane wrote:
> Mario Splivalo <[EMAIL PROTECTED]> writes:
> > Now, when I do this from one connection (psql shell, for instance):
>
> > [A]BEGIN TRANSACTION;
> > [A]SELECT * FROM bla WHERE code_id = 1 FOR UPDATE;
>
> > and then, from another psql i do:
> > [B
15 matches
Mail list logo
