At 20:17 05/09/23, K C Lau wrote:
At 19:15 05/09/23, Simon Riggs wrote:
select distinct on (PlayerID) PlayerID,AtDate from Player a
where PlayerID='0' order by PlayerId, AtDate Desc;
Does that work for you?
Best Regards, Simon Riggs
esdt= explain analyze select distinct on (PlayerID)
While I understand being economical, at some point one crosses the line
to being penny wise and pound foolish.
How much is the data on this server going to be worth?
How much much will it cost you to recover or restore it (assuming that
is even possible if you lose it)?
If your data is worth
Thanks for your help Tom.
While testing 8.1, I found that simple joins take longer in 8.1 than 8.0.
For example the sub query
SELECT doc.doc_documentid FROM document AS doc LEFT JOIN folder_document ON
doc.doc_documentid = folder_document.doc_documentId LEFT JOIN document as
root ON
Is there an performance benefit to using int2 (instead of int4) in cases
where i know i will be well within its numeric range? I want to conserve
storage space and gain speed anywhere i can, but i know some apps simply end
up casting 2byte data to 4byte (like Java int/short).
These int2 values
mydb=# explain analyze select locid from geoip_block where
'216.230.158.50'::inet between start_block and end_block;
QUERY PLAN
Gurpreet Aulakh [EMAIL PROTECTED] writes:
While testing 8.1, I found that simple joins take longer in 8.1 than 8.0.
For example the sub query
SELECT doc.doc_documentid FROM document AS doc LEFT JOIN folder_document ON
doc.doc_documentid = folder_document.doc_documentId LEFT JOIN document as
Cristian Prieto [EMAIL PROTECTED] writes:
mydb=# explain analyze select locid from geoip_block where
'216.230.158.50'::inet between start_block and end_block;
As you see it still using a sequential scan in the table and ignores the
index, any other suggestion?
That two-column index is
On Mon, Sep 26, 2005 at 12:54:05PM -0500, Announce wrote:
Is there an performance benefit to using int2 (instead of int4) in cases
where i know i will be well within its numeric range? I want to conserve
storage space and gain speed anywhere i can, but i know some apps simply end
up casting
On Mon, 2005-26-09 at 12:54 -0500, Announce wrote:
Is there an performance benefit to using int2 (instead of int4) in cases
where i know i will be well within its numeric range?
int2 uses slightly less storage space (2 bytes rather than 4). Depending
on alignment and padding requirements, as
[EMAIL PROTECTED] (Announce) writes:
I KNOW that I am not going to have anywhere near 32,000+ different
genres in my genre table so why use int4? Would that squeeze a few
more milliseconds of performance out of a LARGE song table query
with a genre lookup?
By the way, I see a lot of queries
[EMAIL PROTECTED] (Announce) writes:
I KNOW that I am not going to have anywhere near 32,000+ different
genres in my genre table so why use int4? Would that squeeze a few
more milliseconds of performance out of a LARGE song table query
with a genre lookup?
If the field is immaterial in terms
Ahmad Fajar [EMAIL PROTECTED] wrote
Select ids, keywords from dict where keywords='blabla' ('blabla' is a
single
word);
The table have 200 million rows, I have index the keywords field. On the
first time my query seem to slow to get the result, about 15-60 sec to get
the result. But if I
Chris Browne [EMAIL PROTECTED] writes:
If the field is immaterial in terms of the size of the table, then it
won't help materially.
If you were going to index on it, however, THAT would make it
significant for indices involving the genre column. Fitting more
tuples into each page is a big
Ron Peacetree [EMAIL PROTECTED] writes:
Let's start by assuming that an element is = in size to a cache line and a
node fits into L1 DCache. [ much else snipped ]
So far, you've blithely assumed that you know the size of a cache line,
the sizes of L1 and L2 cache, and that you are working
From: Dann Corbit [EMAIL PROTECTED]
Sent: Sep 26, 2005 5:13 PM
To: Ron Peacetree [EMAIL PROTECTED], pgsql-hackers@postgresql.org,
pgsql-performance@postgresql.org
Subject: RE: [HACKERS] [PERFORM] A Better External Sort?
I think that the btrees are going to be O(n*log(n)) in construction
SECOND ATTEMPT AT POST. Web mailer appears to have
eaten first one. I apologize in advance if anyone gets two
versions of this post.
=r
From: Tom Lane [EMAIL PROTECTED]
Sent: Sep 26, 2005 9:42 PM
Subject: Re: [HACKERS] [PERFORM] A Better External Sort?
So far, you've blithely assumed that you
16 matches
Mail list logo
