On 2013-01-31, haman...@t-online.de wrote:
>
> Pavel Stehlule wrote:
>
>>> >> Hi,
>>> >>
>>> >> I am trying to match items from 2 tables based on a common string.
>>> >> One is a big table which has one column with entries like XY123, ABC44, =
>>> etc
>>> >> The table has an index on that column.
2013/2/2 Pavel Stehule :
> 2013/2/2 :
>> Pavel Stehule wrote:
>>
but maybe https://github.com/dimitri/prefix can help
>>
>> Hi Pavel,
>>
>> thanks - this works perfect. However, it does not seem to play well
>> with the optimizer, so I ended up with
>>
>> select all candidates into
2013/2/2 :
> Pavel Stehule wrote:
>
>>>
>>> but maybe https://github.com/dimitri/prefix can help
>>>
>
> Hi Pavel,
>
> thanks - this works perfect. However, it does not seem to play well
> with the optimizer, so I ended up with
>
> select all candidates into a temp table using prefix operator
> a
Pavel Stehule wrote:
>>
>> but maybe https://github.com/dimitri/prefix can help
>>
Hi Pavel,
thanks - this works perfect. However, it does not seem to play well
with the optimizer, so I ended up with
select all candidates into a temp table using prefix operator
apply all other conditions by
Hello
2013/1/31 :
>
> Pavel Stehlule wrote:
>
>>> >> Hi,
>>> >>
>>> >> I am trying to match items from 2 tables based on a common string.
>>> >> One is a big table which has one column with entries like XY123, ABC44, =
>>> etc
>>> >> The table has an index on that column.
>>> >> The second table
Pavel Stehlule wrote:
>> >> Hi,
>> >>
>> >> I am trying to match items from 2 tables based on a common string.
>> >> One is a big table which has one column with entries like XY123, ABC44, =
>> etc
>> >> The table has an index on that column.
>> >> The second table is, typically, much smaller
>>
2013/1/31 Vincent Veyron :
> Le jeudi 31 janvier 2013 à 11:06 +0100, Pavel Stehule a écrit :
>> 2013/1/31 Vincent Veyron :
>> >
>> > Suppose I have a query of the form
>> >
>> > SELECT my_function(column_1), column_2
>> > FROM my_table
>> > GROUP BY my_function(column_1)
>> > ORDER BY my_function(c
Le jeudi 31 janvier 2013 à 11:06 +0100, Pavel Stehule a écrit :
> 2013/1/31 Vincent Veyron :
> >
> > Suppose I have a query of the form
> >
> > SELECT my_function(column_1), column_2
> > FROM my_table
> > GROUP BY my_function(column_1)
> > ORDER BY my_function(column_1);
> >
> > where my_function i
2013/1/31 Vincent Veyron :
> Le jeudi 31 janvier 2013 à 09:49 +0100, Pavel Stehule a écrit :
>
>> any join where result is related to some function result can be very
>> slow, because estimation will be out and any repeated function
>> evaluation is just expensive.
>>
>
> Hi Pavel,
>
> Thank you fo
Le jeudi 31 janvier 2013 à 09:49 +0100, Pavel Stehule a écrit :
> any join where result is related to some function result can be very
> slow, because estimation will be out and any repeated function
> evaluation is just expensive.
>
Hi Pavel,
Thank you for the correction. Since we're at it, I
2013/1/31 Vincent Veyron :
> Le mercredi 30 janvier 2013 à 11:08 +, wolfg...@noten5.maas-noten.de
> a écrit :
>> Hi,
>>
>> I am trying to match items from 2 tables based on a common string.
>> One is a big table which has one column with entries like XY123, ABC44, etc
>> The table has an index
Le mercredi 30 janvier 2013 à 11:08 +, wolfg...@noten5.maas-noten.de
a écrit :
> Hi,
>
> I am trying to match items from 2 tables based on a common string.
> One is a big table which has one column with entries like XY123, ABC44, etc
> The table has an index on that column.
> The second table
Hi,
I am trying to match items from 2 tables based on a common string.
One is a big table which has one column with entries like XY123, ABC44, etc
The table has an index on that column.
The second table is, typically, much smaller
select from tab1, tab2 where tab1.code = tab2.code;
This wo
Hello.
I have a query which works a bit slow.
It's runned on desktop computer: AMD Athlon X2 2GHz , Win Xp sp2, 1GB ram.
Postgres 8.4.5 with some changes in config:
shared_buffers = 200MB # min 128kB
# (change requires restart)
temp_buffers = 8MB
Hi Alban,
On 7/3/06, Alban Hertroys <[EMAIL PROTECTED]> wrote:
Alexander Farber wrote:
> punbb=> select username, md5('deadbeef' || password) from users where id
> = 4;
> username | md5
> --+--
> Vasja| dcde745cc304742e26d62e683a9ecb0a
>
Alexander Farber wrote:
I wonder, what is faster: fetching 2 columns - the
username and the md5-result and then comparing the
md5 string against the argument in my app, like here:
punbb=> select username, md5('deadbeef' || password) from users where id
= 4;
username | md5
---
Yes, you're probably right.
I'm just trying to ensure, that the slow md5() function isn't
called for every row in the table. If that's not the case, then
the other tiny speed differences are not that important for me.
Your query works too, thanks for the hint.
punbb=> select username, md5('dead
On Mon, Jul 03, 2006 at 03:13:15PM +0200, Alexander Farber wrote:
> Hello,
>
> in my application I'm trying to authenticate users
> against a table called "users". The integer column
> "id" should match, but also an md5 hash of the
> "password" column (salted with a string) should match.
> My auth
Hello,
in my application I'm trying to authenticate users
against a table called "users". The integer column
"id" should match, but also an md5 hash of the
"password" column (salted with a string) should match.
My authentication function (written in C, using libpq)
should return a "username" (is
You're not there yet: you want what Richard said, namely
I realized that it wasn't optimal for all nodes, namely those with a lot
of rows.
So you are absolutely right, I followed the suggestion of Richard and it
works perfect.
Thank you all, I learned a lesson of indexes today...
Poul
=?ISO-8859-1?Q?Poul_M=F8ller_Hansen?= <[EMAIL PROTECTED]> writes:
> explain analyze SELECT * FROM my.table WHERE node = '10' ORDER BY node,
> id DESC LIMIT 1
> QUERY
> PLAN
On Mon, 15 Aug 2005, Poul Møller Hansen wrote:
> I have a problem creating a usable index for the following simple query:
> SELECT * FROM my.table WHERE node = '10' ORDER BY id DESC LIMIT 1
>
> id is a serial, so the query is to find the latest entry to a given node
> and id is the primary key.
I have a problem creating a usable index for the following simple query:
SELECT * FROM my.table WHERE node = '10' ORDER BY id DESC LIMIT 1
id is a serial, so the query is to find the latest entry to a given
node and id is the primary key.
You're not necessarily getting the latest entry, jus
Poul Møller Hansen wrote:
I have a problem creating a usable index for the following simple query:
SELECT * FROM my.table WHERE node = '10' ORDER BY id DESC LIMIT 1
id is a serial, so the query is to find the latest entry to a given node
and id is the primary key.
You're not necessarily getti
I have a problem creating a usable index for the following simple query:
SELECT * FROM my.table WHERE node = '10' ORDER BY id DESC LIMIT 1
id is a serial, so the query is to find the latest entry to a given node
and id is the primary key.
The table contains around 1 million records and the query
idhar Daithankar
Sent: Wednesday, November 19, 2003 6:23 AM
To: Uros
Cc: [EMAIL PROTECTED]
Subject: Re: [GENERAL] Optimizing query
Uros wrote:
> Hello!
>
> I have some trouble getting good results from my query.
>
> here is structure
>
> stat_views
> id| integer
&g
Hello Shridhar,
I use Matthew's solution and it works. Query takes only half a second. I
didn't know that i can index function to.
Thanks
Uros
Wednesday, November 19, 2003, 1:23:26 PM, you wrote:
SD> Uros wrote:
>> Hello!
>>
>> I have some trouble getting good results from my query.
>>
>> h
Uros wrote:
Hello!
I have some trouble getting good results from my query.
here is structure
stat_views
id| integer
id_zone | integer
created | timestamp
I have btree index on created and also id and there is 1633832 records in
that table
First of all I have to manualy set seq_scan
Uros writes:
> explain SELECT count(*) as views FROM stat_views WHERE date_part('day', created) =
> 18;
>
> QUERY PLAN
>
> Aggregate (cost=100101618.08..100101618.08 rows=1
_date_part( created ) );
or add an extra date_part column to your table
which pre-calculates date_part('day',
created) and put an index on this.
Cheers
Matthew
--
- Original Message -
From:
Uros
To: [EMAIL PROTECTED]
Sent: Wednesday, November 19, 2003 10:41
Hello!
I have some trouble getting good results from my query.
here is structure
stat_views
id| integer
id_zone | integer
created | timestamp
I have btree index on created and also id and there is 1633832 records in
that table
First of all I have to manualy set seq_scan to OFF be
31 matches
Mail list logo
