Hi, Don't know if it's exactly what you're looking for but the MADLib
package has utility function for matrix and vector operations.
see: http://doc.madlib.net/latest/group__grp__array.html
Regards,
- Jony
On Fri, Dec 25, 2015 at 9:58 PM, Jim Nasby wrote:
> On 12/24/15 1:56 AM, Pavel Stehule w
Hello.
I would like to create the query like the following.
It work well, but extreme slow.
Is it possible to improve this query like the command ``grep -f keyword
data``?
What kind of Index should I create on url_lists table?
Detail
https://gist.github.com/hiroyuki-sato/574b8ea5d9396e455d60
SE
Hiroyuki Sato wrote:
> Hello.
>
> I would like to create the query like the following.
> It work well, but extreme slow.
> Is it possible to improve this query like the command ``grep -f keyword
> data``?
>
> What kind of Index should I create on url_lists table?
can you show us the create ta
> On 26 Dec 2015, at 13:03, Kevin Waterson wrote:
>
> Thanks, as I am new to postgres, I was unaware of this function.
Actually, the article you referenced makes use of generate_series as well (at
INSERT INTO events), but then for some reason decides to create a
generate_recurrences function
Hiroyuki Sato writes:
> I would like to create the query like the following.
> It work well, but extreme slow.
> ...
> Explain output.
> Nested Loop (cost=0.45..1570856063.28 rows=5712200 width=57)
>-> Index Scan using ix_name_keywords on keywords k (cost=0.28..221.78
> rows=5000 wid
> Tom Lane hat am 27. Dezember 2015 um 19:11 geschrieben:
>
>
> Hiroyuki Sato writes:
> > I would like to create the query like the following.
> > It work well, but extreme slow.
> > ...
> > Explain output.
>
> > Nested Loop (cost=0.45..1570856063.28 rows=5712200 width=57)
> >-> I
What is the correct syntax for calling a function from within an event
trigger, passing in the table name and schema name as parameters to the
function?
The goal is to capture DDL changes to tables for the purpose of turning
on (or off) auditing for production tables. The history_master tab
Andreas Kretschmer writes:
>> Tom Lane hat am 27. Dezember 2015 um 19:11 geschrieben:
>> What in the world is this @~ operator? And what sort of index are
>> you using now, that can accept it? Are the rowcount estimates in
>> the EXPLAIN output accurate? (If they are, it's hardly surprising
>>
It's kind of difficult to figure out what is going on. Apparently, the
function that is called "store.add_history_master()" thinks tg_table_name
is a COLUMN in a table, as evidenced by
"ERROR: column "tg_table_name" does not exist"
Offhand, you probably want to assign TG_TABLE_NAME to a var and th
> Melvin Davidson hat am 27. Dezember 2015 um 19:55
> geschrieben:
>
>
> It's kind of difficult to figure out what is going on. Apparently, the
> function that is called "store.add_history_master()" thinks tg_table_name
> is a COLUMN in a table, as evidenced by
> "ERROR: column "tg_table_name"
Andreas Kretschmer writes:
> The problem is, that tg_table_name isn't declared within a event trigger.
> TG_TAG is defined, it contains the command, for instance CREATE TABLE.
Yeah. According to
http://www.postgresql.org/docs/9.4/static/plpgsql-trigger.html#PLPGSQL-EVENT-TRIGGER
only TG_TAG and
> 9.4 did not offer very complete facilities for finding out what the
> DDL command had done; 9.5 will provide more info.)
>
> regards, tom lane
Really?
http://www.postgresql.org/docs/9.5/static/plpgsql-trigger.html still contains
only TG_EVENT and TG_TAG for Triggers on E
On 2015-12-27 13:19, Tom Lane wrote:
Andreas Kretschmer writes:
The problem is, that tg_table_name isn't declared within a event
trigger.
TG_TAG is defined, it contains the command, for instance CREATE TABLE.
Yeah. According to
http://www.postgresql.org/docs/9.4/static/plpgsql-trigger.htm
On 12/27/2015 12:14 PM, Andreas Kretschmer wrote:
9.4 did not offer very complete facilities for finding out what the
DDL command had done; 9.5 will provide more info.)
regards, tom lane
Really?
http://www.postgresql.org/docs/9.5/static/plpgsql-trigger.html still con
Hi guys, hope everyone's well. I'm in a situation that we find ourselves in
a lot, and I'm wondering if there's an easier option.
I have one view which totals about 60 columns per day. Each day has a "days
ago" column like so:
row_number() over (order by date desc) as days_back
Reason being is t
Do you recreate the views every day? Why?
(stupid smartphone-app, sorry for top-posting)
Am 27. Dezember 2015 22:39:58 MEZ, schrieb Wells Oliver
:
>
>Is there some easier way for me to maintain the structure of the view
>without copying/pasting it 4 times and making one small tweak? I find
>myse
I do not. I just probably tweak it a couple of times a week due to
adding/removal of columns of interest and I just would like to have the
logic in one place if possible...
On Sun, Dec 27, 2015 at 4:03 PM, Andreas Kretschmer wrote:
> Do you recreate the views every day? Why?
>
> (stupid smartpho
Maybe you can create a so called SRF - Funktion (Set Returning Funktion) with
proper parameters to use AS 'create materialized view ... AS select * Form
your_srf_Funktion(param1,param2,...,paramN). Untested, but i think it should
work.
(stupid smartphone-app ...)
Am 27. Dezember 2015 23:04:07
Hello Andreas and Tom
Thank you for replying.
Sorry, I re-created my questions. I was mis-pasted query log on previous
question.
(@~ operator is PGroonga extension (http://pgroonga.github.io))
Please ignore it.
Best regards.
1, Problem.
(1) Following query is exteme slow. (478sec)
SELECT
Hiroyuki Sato writes:
> Sorry, I re-created my questions. I was mis-pasted query log on previous
> question.
> (@~ operator is PGroonga extension (http://pgroonga.github.io))
> [ "like" is actually the operator of interest ]
Ah. You might get some good results with trigram indexes (ie,
contrib/p
Hello Tom.
Thank you for replying.
I re-created index with pg_trgm.
Execution time is 210sec.
Yes It is faster than btree index. But still slow.
It is possible to improve this query speed?
Should I use another query or idex?
Best regards.
1, query
SELECT
u.url
FROM
url_list
21 matches
Mail list logo
