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
OK, I see your problem. Try this :
read this : http://www.postgresql.org/docs/current/static/pgtrgm.html
locate and \i the pg_trgm.sql file
CREATE TABLE dict( s TEXT );
I loaded the english - german dictionary in a test table. I didn't parse
it, so it's just a bunch of 418552 strings, englis
2008/11/15 Tom Lane <[EMAIL PROTECTED]>
> "=?ISO-8859-5?B?svbi0Nv22SDC2Nzn2OjY3Q==?=" <[EMAIL PROTECTED]> writes:
> > I am not. I can't see how materialize can multiply number of rows it gets
> > from sort by 100.
>
> Is it the right-hand input of a merge join? If so you're looking at
> mark/rest
12 matches
Mail list logo
