On 12/21/2016 04:14 AM, Jim Nasby wrote:
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
On Wed, Dec 21, 2016 at 4:14 AM, Craig Ringer wrote:
> Re the patch, I don't like
>
> - static bool master_has_standby_xmin = false;
> + static bool master_has_standby_xmin = true;
>
> without any comment. It's addressed in the comment changes on the
> header
2016-12-21 0:01 GMT+01:00 Tom Lane :
> 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
On 21/12/16 04:06, Craig Ringer wrote:
> 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,
On 21/12/16 04:31, Craig Ringer wrote:
> 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,
>>> +
2016-12-21 4:55 GMT+05:00 David Fetter :
> I see.
>
> I find the following a little easier to follow, and the sleeps still
> work even when very short.
Now I know a little more SQL :) Thank you.
I'm not sure every platform supports microsecond sleeps. But it will
work anyway.
On 12/20/16 10:20 PM, Craig Ringer wrote:
Tools look at pg_class.relfrozenxid and pg_databse.datfrozenxid more
than probably anything else, so making changes that ignores them is
pretty pointless.
Except the only useful way I know of to access *frozenxid is using
age(), and even that is a
Robert Haas writes:
> In commit b30d3ea824c5ccba43d3e942704f20686e7dbab8, when Andres added
> the simplehash stuff, he also added SH_TYPE, SH_ITERATOR, and
> SH_STATUS to typedefs.list. When I subsequently updated typedefs.list
> from the buildfarm in
On 2016/12/21 14:03, Amit Langote wrote:
> OK, updated patch attached.
Oops, incomplete patch that was. Complete patch attached this time.
Thanks,
Amit
diff --git a/src/backend/commands/tablecmds.c b/src/backend/commands/tablecmds.c
index 1c219b03dd..115b98313e 100644
---
At Tue, 20 Dec 2016 22:42:48 -0500, Robert Haas wrote
in
> On Tue, Dec 20, 2016 at 6:18 AM, Fabien COELHO wrote:
> > Would this approach be acceptable, or is modifying Nodes a
Rebased on the current head.
On Tue, Dec 13, 2016 at 12:06 PM, Dilip Kumar wrote:
> On Sat, Dec 10, 2016 at 5:36 PM, Amit Kapila wrote:
>> Few assorted comments:
>
> Thanks for the review
>
>>
>> 1.
>> + else if (needWait)
>> + {
>> + /* Add
On 2016/12/21 13:42, Robert Haas wrote:
> On Tue, Dec 20, 2016 at 9:14 PM, Amit Langote
> wrote:
>> On 2016/12/21 1:45, Alvaro Herrera wrote:
>>> Robert Haas wrote:
On Tue, Dec 20, 2016 at 10:27 AM, Alvaro Herrera
wrote:
>
In commit b30d3ea824c5ccba43d3e942704f20686e7dbab8, when Andres added
the simplehash stuff, he also added SH_TYPE, SH_ITERATOR, and
SH_STATUS to typedefs.list. When I subsequently updated typedefs.list
from the buildfarm in acddbe221b084956a0efd6e4b6c6586e8fd994d7, it of
course removed those
On Tue, Dec 20, 2016 at 9:14 PM, Amit Langote
wrote:
> 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
On Tue, Dec 20, 2016 at 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,
On Tue, Dec 13, 2016 at 8:34 PM, Dilip Kumar wrote:
> I have created two patches as per the suggestion.
>
> 1. mergejoin_refactoring_v2.patch --> Move functionality of
> considering various merge join path into new function.
> 2. parallel_mergejoin_v2.patch -> This adds the
On Tue, Dec 20, 2016 at 8:04 PM, Robert Haas wrote:
> 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
>>
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
>>
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 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
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
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
>
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
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
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
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
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
>>>
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
>
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
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
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
>
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.
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
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 Riggs
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
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,
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
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
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
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
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
>
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
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
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
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
> >
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
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
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:
>
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
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
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,
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
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
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
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
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
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,
>>>
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 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
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
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
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.
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",
>
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
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
> >> ---
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
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
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
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
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
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
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
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
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
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
>
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:
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
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
>> +++
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
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
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
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
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,
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
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
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
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
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
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
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(
> > /*
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
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 */
>
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)
>
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 >
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
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
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
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
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,
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
1 - 100 of 117 matches
Mail list logo