Given an arbitrary function fn(x) returning numeric.
Question: how often is the function executed?
A.
select fn('const'), fn('const');
Answer:
Twice.
This is not a surprize.
B.
select v,v from fn('const') as v; [1]
Answer:
Once.
C.
select v.v,v.v from (select fn('const') as v) as v;
On 24 March 2018 at 14:35, Andres Freund wrote:
> How long does planning take if you repeat this? I wonder if a good chunk
> of those 1.8s is initial loading of plv8.
Maybe, but it also could be the execution of the function, after all,
the planner does invoke immutable functions:
# explain verb
Hi,
On 2018-03-23 21:28:22 +0100, b...@e8s.de wrote:
> I have a table api.issues that has a text column "body" with long texts
> (1000+ chars). I also wrote a custom function "normalizeBody" with plv8 that
> is a simple Text -> Text conversion. Now I created an index applying the
> function to
Hi,
I have a table api.issues that has a text column "body" with long texts (1000+
chars). I also wrote a custom function "normalizeBody" with plv8 that is a
simple Text -> Text conversion. Now I created an index applying the function to
the body column, so I can quickly run
SELECT * FROM api.
On Fri, Mar 23, 2018 at 10:14:19AM -0400, Tom Lane wrote:
! It's conceivable that the OP's problem is actually planning time
! (if the query joins sufficiently many tables) and that restricting
! the cost of the join plan search is really what he needs to do.
Negative. Plnning time 10 to 27 ms. E
Akshay Ballarpure writes:
> I have a query on DB corruption. Is there any way to recover from it
> without losing data ?
You've already lost data, evidently.
> Starting postgresql service: [ OK ]
> psql: FATAL: index "pg_authid_rolname_index" contains unexpected zero page
> at block 0
> HINT:
The problem appeared when I found the queries suddenly taking longer
than usual. Investigation showed that execution time greatly depends
on the way the queries are invoked.
Consider fn(x) simply a macro containing a plain SQL SELECT statement
returning SETOF (further detail follows below):
# SEL
On Fri, Mar 23, 2018 at 12:41:35PM +0100, Laurenz Albe wrote:
! https://www.postgresql.org/docs/current/static/explicit-joins.html
! states towards the end of the page that the search tree grows
! exponentially with the number of relations, and from_collapse_limit
! can be set to control that.
Ye
Laurenz Albe writes:
> Peter wrote:
>> I could not find any documentation or evaluation that would say
>> that from_collapse can have detrimental effects. Even less, which
>> type of queries may suffer from that.
> https://www.postgresql.org/docs/current/static/explicit-joins.html
> states toward
Peter wrote:
> My queries get up to 10 times faster when I disable from_collapse
> (setting from_collapse_limit=1).
>
> After this finding, The pramatic solution is easy: it needs to be
> switched off.
>
> BUT:
> I found this perchance, accidentally (after the queries had been
> running for years
Peter schrieb am 23.03.2018 um 11:03:
> My queries get up to 10 times faster when I disable from_collapse
> (setting from_collapse_limit=1).
>
> After this finding, The pramatic solution is easy: it needs to be
> switched off.
You should post some example queries together with the slow and fast p
My queries get up to 10 times faster when I disable from_collapse
(setting from_collapse_limit=1).
After this finding, The pramatic solution is easy: it needs to be
switched off.
BUT:
I found this perchance, accidentally (after the queries had been
running for years). And this gives me some ques
On Fri, Mar 23, 2018 at 01:29:35PM +0530, Akshay Ballarpure wrote:
> I have a query on DB corruption. Is there any way to recover from it
> without losing data ?
Corrupted pages which need to be zeroed in order to recover the rest is
data lost forever, except if you have a backup you can rollback
Hi,
I have a query on DB corruption. Is there any way to recover from it
without losing data ?
Starting postgresql service: [ OK ]
psql: FATAL: index "pg_authid_rolname_index" contains unexpected zero page
at block 0
HINT: Please REINDEX it.
psql: FATAL: "base/11564" is not a valid data director
14 matches
Mail list logo
