On 2016-12-19 15:25:42 -0500, Robert Haas wrote:
> On Mon, Dec 19, 2016 at 3:13 PM, Peter Eisentraut
> wrote:
> > On 12/9/16 7:52 AM, Robert Haas wrote:
> >> It's kind of ironic, at least IMHO, that the DirectionFunctionCall
> >> macros are anything but direct. Each one is a non-inlined function
Hi,
On 2016-12-19 15:14:50 +0530, Beena Emerson wrote:
> The attached patch removes --with-wal-segsize configure option and adds a
> new initdb option --wal-segsize. The module initdb passes the wal-segsize
> value into an environment variable which is used to overwrite the guc value
> wal_ segmen
Hello,
While investigating a performance issue, I tried to get informations from
pg_stat_statements, however I ran into another issue: it seems that when
using combined queries pg_stat_statements query normalization does not
work properly... 2 queries that should have been mapped to only one
I was expecting the 2 combined queries either to be separated in individual
queries "SELECT data FROM Stuff WHERE id = ?" or in one large queries with
three ?, but not the above result...
Oops, I forgot the attachement, see repeat script on 9.6.1
--
Fabien.
combined_statement_issue.sql
Desc
2016-12-20 9:11 GMT+01:00 Andres Freund :
> On 2016-12-19 15:25:42 -0500, Robert Haas wrote:
> > On Mon, Dec 19, 2016 at 3:13 PM, Peter Eisentraut
> > wrote:
> > > On 12/9/16 7:52 AM, Robert Haas wrote:
> > >> It's kind of ironic, at least IMHO, that the DirectionFunctionCall
> > >> macros are an
Hello Andres,
On Tue, Dec 20, 2016 at 1:58 PM, Andres Freund wrote:
> Hi,
>
> On 2016-12-19 15:14:50 +0530, Beena Emerson wrote:
> > The attached patch removes --with-wal-segsize configure option and adds a
> > new initdb option --wal-segsize. The module initdb passes the wal-segsize
> > value i
On 2016-12-20 09:59:43 +0100, Pavel Stehule wrote:
> In this case some benchmark can be very important (and interesting). I am
> not sure if faster function execution has significant benefit on Vulcano
> like executor.
It's fairly to see function calls as significant overhead. In fact, I
moved thi
On 2016-12-20 01:14:10 -0800, Andres Freund wrote:
> On 2016-12-20 09:59:43 +0100, Pavel Stehule wrote:
> > In this case some benchmark can be very important (and interesting). I am
> > not sure if faster function execution has significant benefit on Vulcano
> > like executor.
>
> It's fairly to se
On 2016-12-20 09:43, Petr Jelinek wrote:
Thanks, this was very useful. We had wrong attribute index arithmetics
in the place where we verify that replica identities match well enough.
Well, I spent a lot of time on the whole thing so I am glad it's not
just
something stupid I did :)
BTW th
2016-12-20 10:28 GMT+01:00 Andres Freund :
> On 2016-12-20 01:14:10 -0800, Andres Freund wrote:
> > On 2016-12-20 09:59:43 +0100, Pavel Stehule wrote:
> > > In this case some benchmark can be very important (and interesting). I
> am
> > > not sure if faster function execution has significant benef
On 20/12/16 10:41, Erik Rijkers wrote:
> On 2016-12-20 09:43, Petr Jelinek wrote:
>
>> Thanks, this was very useful. We had wrong attribute index arithmetics
>> in the place where we verify that replica identities match well enough.
>
> Well, I spent a lot of time on the whole thing so I am glad
Amit Langote wrote:
> diff --git a/src/backend/commands/tablecmds.c
> b/src/backend/commands/tablecmds.c
> index 1c219b03dd..6a179596ce 100644
> --- a/src/backend/commands/tablecmds.c
> +++ b/src/backend/commands/tablecmds.c
> @@ -13297,8 +13297,10 @@ ATExecAttachPartition(List **wqueue, Relation
On Mon, Dec 19, 2016 at 11:05 PM, Robert Haas wrote:
> On Sun, Dec 18, 2016 at 8:54 AM, Amit Kapila wrote:
>>> I committed remove-hash-wrtbuf and fix_dirty_marking_v1 but I've got
>>> some reservations about fix_lock_chaining_v1. ISTM that the natural
>>> fix here would be to change the API cont
I was expecting the 2 combined queries either to be separated in individual
queries "SELECT data FROM Stuff WHERE id = ?" or in one large queries with
three ?, but not the above result...
Oops, I forgot the attachement, see repeat script on 9.6.1
After some quick investigation, I concluded
On 2016-12-20 10:48, Petr Jelinek wrote:
Here is another small thing:
$ psql -d testdb -p 6972
psql (10devel_logical_replication_20161220_1008_db80acfc9d50)
Type "help" for help.
testdb=# drop publication if exists xxx;
ERROR: unrecognized object type: 28
testdb=# drop subscription if exists
On 2016-12-20 10:44:35 +0100, Pavel Stehule wrote:
> 2016-12-20 10:28 GMT+01:00 Andres Freund :
>
> > On 2016-12-20 01:14:10 -0800, Andres Freund wrote:
> > > On 2016-12-20 09:59:43 +0100, Pavel Stehule wrote:
> > > > In this case some benchmark can be very important (and interesting). I
> > am
> >
Hi All,
I have spent some time in reviewing the latest v8 patch from Jesper
and could find some issues which i would like to list down,
1) Firstly, the DATA section in the Makefile is referring to
"pageinspect--1.6.sql" file and currently this file is missing.
+DATA = pageinspect--1.6.sql pagein
Hello again pgdevs,
More investigations conclude that the information is lost by the parser.
From a ;-separated string raw_parser returns a List which are
directly the nodes of the statements, with empty statements silently
skipped.
The Node entry of high level statements (*Stmt) does NOT c
On 12/16/2016 05:48 PM, Robert Haas wrote:
On Thu, Dec 15, 2016 at 8:40 AM, Stephen Frost wrote:
* Heikki Linnakangas (hlinn...@iki.fi) wrote:
On 12/14/2016 04:57 PM, Stephen Frost wrote:
* Peter Eisentraut (peter.eisentr...@2ndquadrant.com) wrote:
On 12/14/16 5:15 AM, Michael Paquier wrote:
On Tue, Dec 20, 2016 at 6:56 AM, Fujii Masao wrote:
> On Tue, Dec 20, 2016 at 1:43 AM, Magnus Hagander
> wrote:
> >
> >
> > On Mon, Dec 19, 2016 at 5:39 PM, Fujii Masao
> wrote:
> >>
> >> Hi,
> >>
> >> Isn't it better to forbid the conbination of the options "-D -", "-F t"
> >> and
> >> "-X str
On 12/16/2016 03:31 AM, Michael Paquier wrote:
On Thu, Dec 15, 2016 at 9:48 PM, Heikki Linnakangas wrote:
The only way to distinguish, is to know about every verifier kind there is,
and check whether rolpassword looks valid as anything else than a plaintext
password. And we already got tripped
On Tue, Dec 20, 2016 at 2:13 AM, Pavel Stehule wrote:
> 2016-12-19 23:28 GMT+01:00 Robert Haas :
>> On Sat, Dec 17, 2016 at 3:30 AM, Pavel Stehule
>> wrote:
>> > -> Bitmap Heap Scan on "Zasilka" (cost=5097.39..5670.64 rows=1
>> > width=12)
>> > (actual time=62.253..62.400 rows=3 loops=231)
>> .
On Tue, Dec 20, 2016 at 6:37 AM, Heikki Linnakangas wrote:
> It's more convenient to carry the type information with the verifier itself,
> in backend code, in pg_dump, etc. Sure, you could have a separate "transfer"
> text format that has the prefix, and strip it out when the datum enters the
> s
2016-12-20 13:55 GMT+01:00 Robert Haas :
> On Tue, Dec 20, 2016 at 2:13 AM, Pavel Stehule
> wrote:
> > 2016-12-19 23:28 GMT+01:00 Robert Haas :
> >> On Sat, Dec 17, 2016 at 3:30 AM, Pavel Stehule >
> >> wrote:
> >> > -> Bitmap Heap Scan on "Zasilka" (cost=5097.39..5670.64 rows=1
> >> > width=1
On Tue, Dec 20, 2016 at 3:28 AM, Andres Freund wrote:
> I do think this has the potential for negative performance
> implications. Consider code like
> /* skip over the page header */
> if (CurrPos % XLogSegSize == 0)
> {
>
On Tue, Dec 20, 2016 at 3:11 AM, Andres Freund wrote:
> I think a more efficient variant would make the function signature look
> something like:
>
> Datum /* directly returned argument */
> pgfunc(
> /* extra information about function call */
> FunctionCallInfo *fcinfo,
>
On 2016-12-20 08:10:29 -0500, Robert Haas wrote:
> We could use the GUC assign hook to compute a mask and a shift, so
> that this could be written as (CurrPos & mask_variable) == 0. That
> would avoid the division instruction, though not the memory access.
I suspect that'd be fine.
> I hope thi
On 2016-12-20 08:15:07 -0500, Robert Haas wrote:
> On Tue, Dec 20, 2016 at 3:11 AM, Andres Freund wrote:
> > I think a more efficient variant would make the function signature look
> > something like:
> >
> > Datum /* directly returned argument */
> > pgfunc(
> > /* extra information about
On Tue, Dec 20, 2016 at 8:21 AM, Andres Freund wrote:
> On 2016-12-20 08:15:07 -0500, Robert Haas wrote:
>> On Tue, Dec 20, 2016 at 3:11 AM, Andres Freund wrote:
>> > I think a more efficient variant would make the function signature look
>> > something like:
>> >
>> > Datum /* directly returned
Heikki,
* Heikki Linnakangas (hlinn...@iki.fi) wrote:
> Even if you have a separate "verifier type" column, it's not fully
> normalized, because there's still a dependency between the verifier
> and verifier type columns. You will always need to look at the
> verifier type to make sense of the ver
On Mon, Dec 19, 2016 at 7:51 PM, Vladimir Rusinov wrote:
>
> On Sat, Dec 17, 2016 at 2:37 PM, Magnus Hagander
> wrote:
>>
>> Attached is an updated patch that does this. As a bonus it simplifies the
>> code a bit. I also fixed an error message that I missed updating in the
>> previous patch.
>
>
On Tue, Dec 20, 2016 at 4:51 AM, Amit Kapila wrote:
> We have mainly four actions for squeeze operation, add tuples to the
> write page, empty overflow page, unlinks overflow page, make it free
> by setting the corresponding bit in overflow page. Now, if we don't
> log the changes to write page a
On 2016-12-20 08:35:05 -0500, Robert Haas wrote:
> On Tue, Dec 20, 2016 at 8:21 AM, Andres Freund wrote:
> > On 2016-12-20 08:15:07 -0500, Robert Haas wrote:
> >> On Tue, Dec 20, 2016 at 3:11 AM, Andres Freund wrote:
> >> > I think a more efficient variant would make the function signature look
>
On 12/1/16 9:47 PM, Andreas Karlsson wrote:
> I think this patch looks good now so I am setting it to ready for committer.
committed, thanks
--
Peter Eisentraut http://www.2ndQuadrant.com/
PostgreSQL Development, 24x7 Support, Remote DBA, Training & Services
--
Sent via pgsql-hac
On Mon, Dec 19, 2016 at 6:15 AM, Kyotaro HORIGUCHI
wrote:
> Hello, recently one of my customer stumbled over an immoderate
> catcache bloat.
This isn't only an issue for negative catcache entries. A long time
ago, there was a limit on the size of the relcache, which was removed
because if you ha
On Tue, Dec 20, 2016 at 7:11 PM, Robert Haas wrote:
> On Tue, Dec 20, 2016 at 4:51 AM, Amit Kapila wrote:
>> We have mainly four actions for squeeze operation, add tuples to the
>> write page, empty overflow page, unlinks overflow page, make it free
>> by setting the corresponding bit in overflow
Recently a client was confused because there was a substantial
difference between the reported table_len of a table and the sum of the
corresponding tuple_len, dead_tuple_len and free_space. The docs are
fairly silent on this point, and I agree that in the absence of
explanation it is confusi
On Tue, Dec 20, 2016 at 8:44 AM, Andres Freund wrote:
>> Advanced Server uses 256, and we had a customer complain recently that
>> 256 wasn't high enough. So apparently the use case for functions with
>> ridiculous numbers of arguments isn't exactly 0.
>
> Well, there's a cost/benefit analysis in
On Tue, Dec 20, 2016 at 9:01 AM, Amit Kapila wrote:
> On Tue, Dec 20, 2016 at 7:11 PM, Robert Haas wrote:
>> On Tue, Dec 20, 2016 at 4:51 AM, Amit Kapila wrote:
>>> We have mainly four actions for squeeze operation, add tuples to the
>>> write page, empty overflow page, unlinks overflow page, ma
On Tue, Dec 20, 2016 at 4:51 AM, Alvaro Herrera
wrote:
> Amit Langote wrote:
>
>> diff --git a/src/backend/commands/tablecmds.c
>> b/src/backend/commands/tablecmds.c
>> index 1c219b03dd..6a179596ce 100644
>> --- a/src/backend/commands/tablecmds.c
>> +++ b/src/backend/commands/tablecmds.c
>> @@ -1
On Tue, Dec 20, 2016 at 7:44 PM, Robert Haas wrote:
> On Tue, Dec 20, 2016 at 9:01 AM, Amit Kapila wrote:
>> On Tue, Dec 20, 2016 at 7:11 PM, Robert Haas wrote:
>>> On Tue, Dec 20, 2016 at 4:51 AM, Amit Kapila
>>> wrote:
We have mainly four actions for squeeze operation, add tuples to the
On 20/12/16 10:56, Erik Rijkers wrote:
> On 2016-12-20 10:48, Petr Jelinek wrote:
>
> Here is another small thing:
>
> $ psql -d testdb -p 6972
> psql (10devel_logical_replication_20161220_1008_db80acfc9d50)
> Type "help" for help.
>
> testdb=# drop publication if exists xxx;
> ERROR: unrecogni
On Tue, Dec 20, 2016 at 1:44 AM, Alvaro Herrera
wrote:
> Fujii Masao wrote:
>
>> Regarding this feature, there are some loose ends. We should work on
>> and complete them until the release.
>
> Please list these in https://wiki.postgresql.org/wiki/Open_Items so that we
> don't forget.
Yep, added!
On Sat, Dec 17, 2016 at 5:46 AM, Amit Kapila wrote:
> Yeah, but we are planning to add a generic flag in WaitEvent structure
> which can be used for similar purpose. However, as per your
> suggestion, I have changed it only for Win32 port. Also, I kept the
> change in ModifyWaitEvent API as that
On 20 December 2016 at 21:59, Robert Haas wrote:
> We could implement this by having
> some process, like the background writer,
> SendProcSignal(PROCSIG_HOUSEKEEPING) to every process in the system
> every 10 minutes or so.
... on a rolling basis.
Otherwise that'll be no fun at all, especially
On Tue, Dec 20, 2016 at 2:46 PM, Michael Paquier
wrote:
> On Tue, Dec 20, 2016 at 2:31 PM, Masahiko Sawada
> wrote:
>> Do we need to consider the sorting method and the selecting k-th
>> latest LSN method?
>
> Honestly, nah. Tests are showing that there are many more bottlenecks
> before that wi
On Tue, Dec 20, 2016 at 7:11 AM, Simon Riggs wrote:
> On 19 December 2016 at 21:29, Peter Eisentraut
> wrote:
>> On 12/16/16 8:52 PM, Robert Haas wrote:
>>> If the explanation is just a few sentences long, I see no reason not
>>> to include it in the release notes.
>>
>> As far as I can tell from
Hi,
On 12/20/2016 05:55 AM, Ashutosh Sharma wrote:
Attached is the revised patch. Please have a look and let me know your
feedback. I have also changed the status for this patch in the
upcoming commitfest to "needs review". Thanks.
I was planning to submit a new version next week for CF/Janu
Craig Ringer writes:
> On 20 December 2016 at 21:59, Robert Haas wrote:
>> We could implement this by having
>> some process, like the background writer,
>> SendProcSignal(PROCSIG_HOUSEKEEPING) to every process in the system
>> every 10 minutes or so.
> ... on a rolling basis.
I don't understan
Robert Haas writes:
> Well, I'm hoping there is a way to have a fast-path and a slow-path
> without slowing things down too much.
Seems like this discussion has veered way off into the weeds.
I suggest we confine it to the stated topic; if you want to discuss
ways to optimize V1 protocol (or inve
Andrew Dunstan writes:
> Recently a client was confused because there was a substantial
> difference between the reported table_len of a table and the sum of the
> corresponding tuple_len, dead_tuple_len and free_space. The docs are
> fairly silent on this point, and I agree that in the absence
On 20 December 2016 at 15:03, Fujii Masao wrote:
> API for crash recovery will never be changed. That is, crash recovery needs
> neither recovery.trigger nor standby.trigger. When the server starts a crash
> recovery without any trigger file, any recovery parameter settings in
> postgresql.conf a
Robert Haas wrote:
> On Tue, Dec 20, 2016 at 4:51 AM, Alvaro Herrera
> wrote:
> > Amit Langote wrote:
> >
> >> diff --git a/src/backend/commands/tablecmds.c
> >> b/src/backend/commands/tablecmds.c
> >> index 1c219b03dd..6a179596ce 100644
> >> --- a/src/backend/commands/tablecmds.c
> >> +++ b/src/
Hi Jesper,
> I was planning to submit a new version next week for CF/January, so I'll
> review your changes with the previous feedback in mind.
>
> Thanks for working on this !
As i was not seeing any updates from you for last 1 month, I thought
of working on it. I have created a commit-fest entr
On Tue, Dec 20, 2016 at 10:27 AM, Alvaro Herrera
wrote:
> Even if we decide to keep the message, I think it's not very good
> wording anyhow; as a translator I disliked it on sight. Instead of
> "skipping scan to validate" I would use "skipping validation scan",
> except that it's not clear what
On Tue, Dec 20, 2016 at 08:34:19AM -0500, Stephen Frost wrote:
> Heikki,
>
> * Heikki Linnakangas (hlinn...@iki.fi) wrote:
> > Even if you have a separate "verifier type" column, it's not fully
> > normalized, because there's still a dependency between the
> > verifier and verifier type columns. Y
On Tue, Dec 20, 2016 at 11:11:36AM +0530, amul sul wrote:
> On Tue, Dec 20, 2016 at 12:21 AM, David Fetter wrote:
> > On Thu, Nov 24, 2016 at 09:16:53AM +0530, amul sul wrote:
> >> Hi All,
> >>
> >> I would like to take over pg_background patch and repost for
> >> discussion and review.
> >
> > Th
Robert Haas wrote:
> On Tue, Dec 20, 2016 at 10:27 AM, Alvaro Herrera
> wrote:
> > Even if we decide to keep the message, I think it's not very good
> > wording anyhow; as a translator I disliked it on sight. Instead of
> > "skipping scan to validate" I would use "skipping validation scan",
> > e
I just had a client issue with table bloat that I traced back to a
stale xmin value in a replication slot. xmin value from hot standby
feedback is stored in replication slot and used for vacuum xmin
calculation. If hot standby feedback is turned off while walreceiver
is active then the xmin gets re
On Mon, Dec 19, 2016 at 10:59 PM, Robert Haas wrote:
> On Sun, Dec 18, 2016 at 10:00 PM, Amit Langote
> wrote:
>> Here are updated patches including the additional information.
>
> Thanks. Committed 0001. Will have to review the others when I'm less tired.
0002. Can you add a test case for the
On Tue, Dec 20, 2016 at 10:09 AM, Tom Lane wrote:
> Craig Ringer writes:
>> On 20 December 2016 at 21:59, Robert Haas wrote:
>>> We could implement this by having
>>> some process, like the background writer,
>>> SendProcSignal(PROCSIG_HOUSEKEEPING) to every process in the system
>>> every 10 mi
On 12/20/2016 10:01 AM, Tom Lane wrote:
Andrew Dunstan writes:
Recently a client was confused because there was a substantial
difference between the reported table_len of a table and the sum of the
corresponding tuple_len, dead_tuple_len and free_space. The docs are
fairly silent on this poin
Robert Haas wrote:
> Implement table partitioning.
I thought it was odd to use rd_rel->reloftype as a boolean in
ATExecAttachPartition, but apparently we do it elsewhere too, so let's
leave that complaint for another day.
What I also found off in the same function is that we use
SearchSysCacheCop
On 12/19/2016 01:29 PM, Peter Eisentraut wrote:
> On 12/16/16 8:52 PM, Robert Haas wrote:
>> > If the explanation is just a few sentences long, I see no reason not
>> > to include it in the release notes.
> As far as I can tell from the latest posted patch, the upgrade
> instructions are
>
> - To
On Tue, Dec 20, 2016 at 3:51 AM, Robert Haas wrote:
> On Fri, Dec 16, 2016 at 5:16 AM, Mithun Cy
> wrote:
>
>> Shouldn't _hash_doinsert() be using the cache, too
>>>
>>
>> Yes, we have an opportunity there, added same in code. But one difference
>> is at the end at-least once we need to read the
Robert Haas writes:
> On Tue, Dec 20, 2016 at 10:09 AM, Tom Lane wrote:
>> I don't understand why we'd make that a system-wide behavior at all,
>> rather than expecting each process to manage its own cache.
> Individual backends don't have a really great way to do time-based
> stuff, do they? I
I wrote:
> I've been thinking about how to fix the problem Andreas Seltenreich
> reported at
> https://postgr.es/m/87eg1y2s3x@credativ.de
Attached is a proposed patch that deals with the problems discussed
here and in <26706.1482087...@sss.pgh.pa.us>. Is anyone interested
in reviewing this, o
Hi Postgres Devs,
I had a suggestion regarding the output pg_ctl gives when you use it to
start the postgres server. At first I was going to write a patch, but then
I decided to just ask you guys first to see what you think.
I had an issue earlier where I was trying to upgrade my postgres databa
On 12/20/16 3:31 PM, Ryan Murphy wrote:
> I'm concerned some new users may not understand this behavior of pg_ctl,
> so I wanted to suggest that we add some additional messaging after
> "server starting" - something like:
>
> $ pg_ctl -D datadir -l logfile start
> server starting
> (to wait for co
On Tue, Dec 20, 2016 at 03:43:11PM -0500, Peter Eisentraut wrote:
> On 12/20/16 3:31 PM, Ryan Murphy wrote:
> > I'm concerned some new users may not understand this behavior of pg_ctl,
> > so I wanted to suggest that we add some additional messaging after
> > "server starting" - something like:
> >
Ryan Murphy writes:
> I'm concerned some new users may not understand this behavior of pg_ctl, so
> I wanted to suggest that we add some additional messaging after "server
> starting" - something like:
> $ pg_ctl -D datadir -l logfile start
> server starting
> (to wait for confirmation that serve
Peter Eisentraut writes:
> Maybe the fix is to make --wait the default?
I was wondering about that too ... does anyone remember the rationale
for the current behavior? But the message for the non-wait case seems
like it could stand to be improved independently of that.
r
Tom Lane wrote:
> Ryan Murphy writes:
> > I'm concerned some new users may not understand this behavior of pg_ctl, so
> > I wanted to suggest that we add some additional messaging after "server
> > starting" - something like:
>
> > $ pg_ctl -D datadir -l logfile start
> > server starting
> > (to
On Tue, Dec 20, 2016 at 1:49 PM, Tom Lane wrote:
> Peter Eisentraut writes:
> > Maybe the fix is to make --wait the default?
>
> I was wondering about that too ... does anyone remember the rationale
> for the current behavior? But the message for the non-wait case seems
> like it could stand to
On Wed, Dec 21, 2016 at 1:08 AM, David Fetter wrote:
> Would a view that shows only what's to the left of the first semicolon
> suit this purpose?
Of course it would, you would just need to make the routines now
checking the shape of MD5 and SCRAM identifiers available at SQL level
and feed the s
On 12/20/16 3:49 PM, Tom Lane wrote:
> Peter Eisentraut writes:
>> Maybe the fix is to make --wait the default?
> I was wondering about that too ... does anyone remember the rationale
> for the current behavior?
Probably because that didn't work reliably before pg_ctl learned how to
get the right
On Tue, Dec 20, 2016 at 10:38 PM, Fujii Masao wrote:
> On Mon, Dec 19, 2016 at 7:51 PM, Vladimir Rusinov wrote:
>> The server must also be configured with max_wal_senders set high
>> enough to leave at least one session available for the backup.
>
> I think that it's better to explain explicitly
On Wed, Sep 21, 2016 at 12:52 PM, Heikki Linnakangas wrote:
> I find this unification business really complicated. I think it'd be simpler
> to keep the BufFiles and LogicalTapeSets separate, and instead teach
> tuplesort.c how to merge tapes that live on different
> LogicalTapeSets/BufFiles. Or r
Pavel Stehule writes:
> I am trying to fix slow query on PostgreSQL 9.5.4.
> The data are almost in RAM
If it's all in RAM, you'd likely be well-served to lower random_page_cost.
It looks to me like the planner is estimating pretty accurately how many
heap fetches will be eliminated by using the
David,
* David Fetter (da...@fetter.org) wrote:
> On Tue, Dec 20, 2016 at 08:34:19AM -0500, Stephen Frost wrote:
> > * Heikki Linnakangas (hlinn...@iki.fi) wrote:
> > > Even if you have a separate "verifier type" column, it's not fully
> > > normalized, because there's still a dependency between t
On Tue, Dec 20, 2016 at 3:10 PM, Tom Lane wrote:
> Robert Haas writes:
>> On Tue, Dec 20, 2016 at 10:09 AM, Tom Lane wrote:
>>> I don't understand why we'd make that a system-wide behavior at all,
>>> rather than expecting each process to manage its own cache.
>
>> Individual backends don't have
On Tue, Dec 20, 2016 at 06:14:40PM -0500, Stephen Frost wrote:
> David,
>
> * David Fetter (da...@fetter.org) wrote:
> > On Tue, Dec 20, 2016 at 08:34:19AM -0500, Stephen Frost wrote:
> > > * Heikki Linnakangas (hlinn...@iki.fi) wrote:
> > > > Even if you have a separate "verifier type" column, it
On Mon, Dec 19, 2016 at 09:30:32PM +0500, Andrew Borodin wrote:
> 2016-12-19 4:21 GMT+05:00 David Fetter :
> > Couldn't it sleep in increments smaller than a second? Like maybe
> > milliseconds? Also, it's probably cleaner (or at least more
> > comprehensible) to write something using format() an
On 9 December 2016 at 13:00, Robert Haas wrote:
> That might be good, because then we wouldn't have to maintain two
> copies of the code.
So why are there two things at all? Why is this being worked on as
well as Peter's patch? What will that give us?
--
Simon Riggshttp://www.2
David,
* David Fetter (da...@fetter.org) wrote:
> On Tue, Dec 20, 2016 at 06:14:40PM -0500, Stephen Frost wrote:
> > * David Fetter (da...@fetter.org) wrote:
> > > On Tue, Dec 20, 2016 at 08:34:19AM -0500, Stephen Frost wrote:
> > > > * Heikki Linnakangas (hlinn...@iki.fi) wrote:
> > > > > Even if
On Tue, Dec 20, 2016 at 2:53 PM, Robert Haas wrote:
>> What I have in mind is something like the attached patch. It refactors
>> LogicalTapeRead(), LogicalTapeWrite() etc. functions to take a LogicalTape
>> as argument, instead of LogicalTapeSet and tape number. LogicalTapeSet
>> doesn't have the
Thank you for the discussion.
At Tue, 20 Dec 2016 15:10:21 -0500, Tom Lane wrote in
<23492.1482264...@sss.pgh.pa.us>
> The bigger picture here though is that we used to have limits on syscache
> size, and we got rid of them (commit 8b9bc234a, see also
> https://www.postgresql.org/message-id/flat
At Tue, 20 Dec 2016 23:47:22 +0900, Fujii Masao wrote
in
> On Tue, Dec 20, 2016 at 2:46 PM, Michael Paquier
> wrote:
> > On Tue, Dec 20, 2016 at 2:31 PM, Masahiko Sawada
> > wrote:
> >> Do we need to consider the sorting method and the selecting k-th
> >> latest LSN method?
> >
> > Honestly,
On Tue, Dec 20, 2016 at 9:23 PM, Heikki Linnakangas wrote:
> On 12/16/2016 03:31 AM, Michael Paquier wrote:
> Actually, it does still perform that check. There's a new function,
> plain_crypt_verify, that passwordcheck uses now. plain_crypt_verify() is
> intended to work with any future hash forma
On 21 December 2016 at 00:52, Ants Aasma wrote:
> The simple fix seems to be to always send out at least one feedback
> message on each connect regardless of hot_standby_feedback setting.
I agree.
> Patch attached. Looks like this goes back to version 9.4. It could
> conceivably cause issues fo
On 2016/12/21 1:45, Alvaro Herrera wrote:
> Robert Haas wrote:
>> On Tue, Dec 20, 2016 at 10:27 AM, Alvaro Herrera
>> wrote:
>>> Even if we decide to keep the message, I think it's not very good
>>> wording anyhow; as a translator I disliked it on sight. Instead of
>>> "skipping scan to validate"
On Wed, Dec 21, 2016 at 11:14 AM, Craig Ringer wrote:
> I didn't see this in the CF app so I created it in
> https://commitfest.postgresql.org/12/ as
> https://commitfest.postgresql.org/12/924/ . I couldn't find your
> PostgreSQL community username, so please log in and set yourself as
> author. I
On 20 December 2016 at 15:03, Petr Jelinek wrote:
>> The biggest change in this patch, and the main intrusive part, is that
>> procArray->replication_slot_catalog_xmin is no longer directly used by
>> vacuum. Instead, a new ShmemVariableCache->oldestCatalogXmin field is
>> added, with a correspon
Why do functions that accept composite types delay type resolution until
execution? I have a naive patch that speeds up plpy.execute() by 8% by
caching interred python strings for the dictionary key names (which are
repeated over and over). The next step is to just pre-allocate those
strings as
On 20 December 2016 at 15:03, Petr Jelinek wrote:
> But in 0003 I don't understand following code:
>> + if (endpos != InvalidXLogRecPtr && !do_start_slot)
>> + {
>> + fprintf(stderr,
>> + _("%s: cannot use --create-slot or --drop-slot
>> together w
On Tue, Dec 20, 2016 at 6:18 AM, Fabien COELHO wrote:
> Would this approach be acceptable, or is modifying Nodes a no-go area?
>
> If it is acceptable, I can probably put together a patch and submit it.
>
> If not, I suggest to update the documentation to tell that
> pg_stat_statements does not wo
On Tue, Dec 20, 2016 at 8:14 PM, Peter Geoghegan wrote:
> Without meaning to sound glib, unification is the process by which
> parallel CREATE INDEX has the leader read temp files from workers
> sufficient to complete its final on-the-fly merge.
That's not glib, but you can't in the end define Bu
On Tue, Dec 20, 2016 at 7:32 PM, Simon Riggs wrote:
> On 9 December 2016 at 13:00, Robert Haas wrote:
>> That might be good, because then we wouldn't have to maintain two
>> copies of the code.
>
> So why are there two things at all? Why is this being worked on as
> well as Peter's patch? What wi
I've been looking at the performance of SPI calls within plpython.
There's a roughly 1.5x difference from equivalent python code just in
pulling data out of the SPI tuplestore. Some of that is due to an
inefficiency in how plpython is creating result dictionaries, but fixing
that is ultimately
On 17 December 2016 at 00:13, Robert Haas wrote:
> On Thu, Dec 15, 2016 at 3:02 AM, Craig Ringer wrote:
>> I really wish we could just change the pg_stat_activity and
>> pg_stat_replication xid fields to be epoch qualified in a 64-bit wide
>> 'fullxid' type, or similar.
>
> I think that approach
1 - 100 of 117 matches
Mail list logo
