Hello
I am returning to topic, that I opened with discussion about enhancing
protocol to support access to host variables.
There was a second idea about joining host variables and session
variables. This can be implemented without protocol enhancing, but it
is only one way tool - we are able read
> From: Tom Lane [t...@sss.pgh.pa.us]
> Sent: Saturday, July 28, 2012 9:46 PM
Amit kapila writes:
>>> I think it should be removed with proc_exit hook just like the main
>>> postmaster.pid file.
>> external_pid_file is created first time when it is enabled in postgresql.conf
>> I think it should
Peter Geoghegan writes:
> On 28 July 2012 17:15, Tom Lane wrote:
>> IMV smgr is pretty vestigial. I wouldn't recommend loading more
>> functionality onto that layer, because it's as likely as not that
>> we'll just get rid of it someday.
> Agreed. I recently found myself reading a paper written
On 28 July 2012 17:15, Tom Lane wrote:
> IMV smgr is pretty vestigial. I wouldn't recommend loading more
> functionality onto that layer, because it's as likely as not that
> we'll just get rid of it someday.
Agreed. I recently found myself reading a paper written by Stonebraker
back in the Berk
Heikki Linnakangas writes:
> On 29.07.2012 00:50, Tom Lane wrote:
>> We could possibly extend the API to allow a different type to be used
>> for this, but then it wouldn't be "reconstructed data" in any sense of
>> the word; so I think it'd be abuse of the concept --- which would come
>> back to
On Sat, Jul 7, 2012 at 9:17 PM, Satoshi Nagayasu wrote:
> Hi,
>
> Jeff Janes has pointed out that my previous patch could hold
> a number of the dirty writes only in single local backend, and
> it could not hold all over the cluster, because the counter
> was allocated in the local process memory.
On 29.07.2012 00:50, Tom Lane wrote:
Heikki Linnakangas writes:
Also, I wonder if we really need to reconstruct the "previous" value in
a RANGESTRAT_ADJACENT search. ISTM we only need to remember which of the
two lines we are chasing. For example, if you descend to quadrant 2
because there migh
Heikki Linnakangas writes:
> Also, I wonder if we really need to reconstruct the "previous" value in
> a RANGESTRAT_ADJACENT search. ISTM we only need to remember which of the
> two lines we are chasing. For example, if you descend to quadrant 2
> because there might be a point there that lies
On Fri, Jul 27, 2012 at 1:27 PM, Merlin Moncure wrote:
>
> One point of concern though is that (following a bit of testing)
> alter table foo add exclude using btree (id with =);
> ...is always strictly slower for inserts than
> alter table foo add primary key(id);
>
> This is probably because it
On 23.07.2012 10:37, Alexander Korotkov wrote:
On Fri, Jul 20, 2012 at 3:48 PM, Heikki Linnakangas<
heikki.linnakan...@enterprisedb.com> wrote:
It would be nice to have an introduction, perhaps as a file comment at the
top of rangetypes_spgist.c, explaining how the quad tree works. I have a
ge
The bitmap heap scan can benefit quite a bit from
effective_io_concurrency on RAID system (and to some extent even on
single spindle systems)
However, the planner isn't aware of this. So you have to just be
lucky to have it choose the bitmap heap scan instead of something else
that can't benefit
On Fri, 2012-07-27 at 15:27 -0500, Merlin Moncure wrote:
> The covering index/uniqueness use case adds
> legitimacy to the INDEX clause of exclusion constraints IMNSHO.
Yes, I think it would be worth revisiting the idea.
> One point of concern though is that (following a bit of testing)
> alter t
On Jul 27, 2012, at 3:26 PM, Tom Lane wrote:
> Hm. We have seen similar symptoms reported by people using broken
> openssl installations. I've never tracked down the details but I
> suspect header-vs-library mismatches. Is it possible there are some
> pre-ML openssl-related files hanging abo
Amit kapila writes:
>> I think it should be removed with proc_exit hook just like the main
>> postmaster.pid file.
> external_pid_file is created first time when it is enabled in postgresql.conf
> I think it should be removed once the parameter external_pid_file is unset;
Unset? If that parame
Satoshi Nagayasu writes:
> Hi,
> I'm thinking of adding new probes to trace smgr activities.
> In this implementation, I just found that md.c has its own probes
> within it, but I'm wondering why we do not have those probes
> within the generic smgr routines itself.
IMV smgr is pretty vestigial.
Hello
2012/7/27 Tom Lane :
> Pavel Stehule writes:
>> 2012/7/26 David Fetter :
> How about
> \gset var1,,,var2,var3...
>
I don't like this - you can use fake variable - and ignoring some
variable has no big effect on client
>
>>> Why assign to a variable you'll never use?
>
>> s
On Fri, Jul 27, 2012 at 08:29:20AM -0400, Robert Haas wrote:
> >> Yes, that would be a problem because the WAL records are deleted by
> >> pg_upgrade. Does a shutdown of the standby not already replay all WAL
> >> logs? We could also just require them to just start the standby in
> >> master mod
>From: pgsql-hackers-ow...@postgresql.org [pgsql-hackers-ow...@postgresql.org]
>on behalf of Peter Eisentraut [pete...@gmx.net]
> Sent: Friday, July 27, 2012 10:39 AM
> It seems strange that the external_pid_file is never removed. There is
> even a C comment about it:
> /* Should we remove the
Hi,
I'm thinking of adding new probes to trace smgr activities.
In this implementation, I just found that md.c has its own probes
within it, but I'm wondering why we do not have those probes
within the generic smgr routines itself.
Which would be a better choice?
Any ideas or comments?
Regards
19 matches
Mail list logo
