On Mon, Nov 17, 2008 at 6:14 PM, Dimi Paun <[EMAIL PROTECTED]> wrote:
>
> On Mon, 2008-11-17 at 10:40 -0700, Scott Marlowe wrote:
>> I'm guessing a fair bit of that time is pgadminIII prettifying the
>> output for you, etc. I.e. it's not all transfer time. Hard to say
>> without hooking some kind
On Mon, 2008-11-17 at 10:40 -0700, Scott Marlowe wrote:
> I'm guessing a fair bit of that time is pgadminIII prettifying the
> output for you, etc. I.e. it's not all transfer time. Hard to say
> without hooking some kind of profiler in pgadminIII. Is psql running
> local and pgadminIII remotely
On Nov 17, 2008, at 12:40 PM, Scott Marlowe wrote:
On Mon, Nov 17, 2008 at 10:31 AM, Dimi Paun <[EMAIL PROTECTED]> wrote:
On Mon, 2008-11-17 at 10:16 -0700, Scott Marlowe wrote:
Ahhh. Keep in mind that if you just run the query, pgadminIII will
tell you how long it took to run AND return al
On Mon, Nov 17, 2008 at 10:31 AM, Dimi Paun <[EMAIL PROTECTED]> wrote:
>
> On Mon, 2008-11-17 at 10:16 -0700, Scott Marlowe wrote:
>> Ahhh. Keep in mind that if you just run the query, pgadminIII will
>> tell you how long it took to run AND return all the data across the
>> network, so it will def
On Mon, 2008-11-17 at 10:16 -0700, Scott Marlowe wrote:
> Ahhh. Keep in mind that if you just run the query, pgadminIII will
> tell you how long it took to run AND return all the data across the
> network, so it will definitely take longer then. But most of that's
> network io wait so it's not a
On Mon, Nov 17, 2008 at 10:07 AM, Dimi Paun <[EMAIL PROTECTED]> wrote:
>
> On Mon, 2008-11-17 at 09:53 -0700, Scott Marlowe wrote:
>>
>> Are you saying it's excessive you need the compound query? Cause
>> that's running in 91microseconds as pointed out by Alan.
>
> Of course, my bad. I read that a
On Mon, 2008-11-17 at 09:53 -0700, Scott Marlowe wrote:
>
> Are you saying it's excessive you need the compound query? Cause
> that's running in 91microseconds as pointed out by Alan.
Of course, my bad. I read that as 91ms ().
Confusion came from the fact that pgadminIII reports the query
taki
On Mon, Nov 17, 2008 at 8:53 AM, Dimi Paun <[EMAIL PROTECTED]> wrote:
> Hi folks,
>
> I have a simple table that keeps track of a user's access history.
> It has a a few fields, but the important ones are:
> - ownerId: the user's ID, a int8
> - accessTS: the timestamp of the record
>
> The table
On Monday 17 November 2008, Dimi Paun <[EMAIL PROTECTED]> wrote:
>> It takes 0.091s (!):
> perpedes_db=# EXPLAIN ANALYZE SELECT * FROM triphistory WHERE ownerId =
> 10015 ORDER BY accessTS DESC LIMIT 5; QUERY PLAN
> -
>
Hi folks,
I have a simple table that keeps track of a user's access history.
It has a a few fields, but the important ones are:
- ownerId: the user's ID, a int8
- accessTS: the timestamp of the record
The table right now is small, only 1942 records.
The user I test with (10015) has only 89 en
10 matches
Mail list logo
