On Wed, Dec 10, 2014 at 12:46 PM, Amit Kapila wrote:
> On Tue, Dec 9, 2014 at 7:21 PM, Alvaro Herrera
> wrote:
>>
>> Amit Kapila wrote:
>> > On Tue, Dec 9, 2014 at 1:42 AM, Robert Haas
>> > wrote:
>> > > On Mon, Dec 8, 2014 at 2:56 PM, Andres Freund
>> > wrote:
>> > > >> I don't think that's
On Wed, Dec 10, 2014 at 12:33 PM, Amit Kapila wrote:
> On Tue, Dec 9, 2014 at 11:44 PM, Josh Berkus wrote:
>> On 12/09/2014 12:17 AM, Amit Langote wrote:
>> >> Now if user wants to define multi-column Partition based on
>> >> > monthly_salary and annual_salary, how do we want him to
>> >> > spe
We haven't heard anything from Horiguchi-san and Hanada-san for almost a
week. So, I am fine marking it as "ready for committer". What do you say?
On Wed, Dec 10, 2014 at 8:48 AM, Etsuro Fujita
wrote:
> Hi Ashutosh,
>
> Thanks for the review!
>
> (2014/11/28 18:14), Ashutosh Bapat wrote:
>
>> O
Alvaro Herrera writes:
> Andrew Dunstan wrote:
>> I seriously doubt it, although I could be wrong. Unless someone can show a
>> significant performance gain from using physical order, which would be a bit
>> of a surprise to me, I would just stick with logical ordering as the
>> default.
> Well,
Josh Berkus writes:
> Question on COPY, though: there's reasons why people would want COPY to
> dump in either physical or logical order. If you're doing COPY to
> create CSV files for output, then you want the columns in logical order.
> If you're doing COPY for pg_dump, then you want them in p
On Tue, Dec 9, 2014 at 11:11 AM, Mark Dilger wrote:
> The call:
>
> reserveFromBuffer(&buffer, sizeof(VARHDRSZ))
>
> is assuming that the size of varlena header is the same
> size as the type used to return that size, which happens
> to be so, but someone could easily change that macro
> t
On Tue, Dec 9, 2014 at 7:21 PM, Alvaro Herrera
wrote:
>
> Amit Kapila wrote:
> > On Tue, Dec 9, 2014 at 1:42 AM, Robert Haas
wrote:
> > > On Mon, Dec 8, 2014 at 2:56 PM, Andres Freund
> > wrote:
> > > >> I don't think that's mutually exclusive with the idea of
> > > >> partitions-as-tables. I m
On Tue, Dec 9, 2014 at 11:44 PM, Josh Berkus wrote:
> On 12/09/2014 12:17 AM, Amit Langote wrote:
> >> Now if user wants to define multi-column Partition based on
> >> > monthly_salary and annual_salary, how do we want him to
> >> > specify the values. Basically how to distinguish which values
>
On Thu, Dec 4, 2014 at 9:26 PM, Heikki Linnakangas
wrote:
> On 12/04/2014 01:47 PM, Petr Jelinek wrote:
>>
>> On 04/12/14 12:26, Heikki Linnakangas wrote:
>>>
>>> On 12/04/2014 01:16 PM, Petr Jelinek wrote:
On 04/12/14 10:42, Heikki Linnakangas wrote:
>
> On 12/03/2014 04:54 PM,
Hi Ashutosh,
Thanks for the review!
(2014/11/28 18:14), Ashutosh Bapat wrote:
On Thu, Nov 27, 2014 at 3:52 PM, Etsuro Fujita
mailto:fujita.ets...@lab.ntt.co.jp>> wrote:
(2014/11/17 17:55), Ashutosh Bapat wrote:
Here are my review comments for patch fdw-inh-3.patch.
Tests
There is an interesting thread about strcoll() overhead over on -general:
http://www.postgresql.org/message-id/cab25xexnondrmc1_cy3jvmb0tmydm38ef9q2d7xla0rbncj...@mail.gmail.com
My guess was that this person experienced a rather unexpected downside
of spilling to disk when sorting on a text attri
Alex Shulgin wrote:
> The 2PC part requires extending bool flag to fit the trunc flag, is this
> approach sane? Given that 2PC transaction should survive server
> restart, it's reasonable to expect it to also survive the upgrade, so I
> see no clean way of adding another bool field to the
> TwoPh
Andrew Dunstan wrote:
>
> On 12/09/2014 06:19 PM, Josh Berkus wrote:
> >On 12/09/2014 09:41 AM, Alvaro Herrera wrote:
> >>The first thing where this matters is tuple descriptor expansion in
> >>parse analysis; at this stage, things such as "*" (in "select *") are
> >>turned into a target list, whi
The call:
reserveFromBuffer(&buffer, sizeof(VARHDRSZ))
is assuming that the size of varlena header is the same
size as the type used to return that size, which happens
to be so, but someone could easily change that macro
to:
#define VARHDRSZ ((int64) sizeof(int32))
And you'd wan
On Sun, Nov 23, 2014 at 3:59 PM, Andres Freund wrote:
>> >> The heavyweight locking issue is really killing me, though.
>> >
>> > I don't really understand why you're not content with just detecting
>> > deadlocks for now. Everything else seems like bells and whistles for
>> > later.
>>
>> I don't
On 12/09/2014 06:19 PM, Josh Berkus wrote:
On 12/09/2014 09:41 AM, Alvaro Herrera wrote:
The first thing where this matters is tuple descriptor expansion in
parse analysis; at this stage, things such as "*" (in "select *") are
turned into a target list, which must be sorted according to attlogn
On 5 Dec 2014, at 22:41, Jim Nasby wrote:
>
>
> Perhaps we should also officially recommend production servers be setup to
> create core files. AFAIK the only downside is the time it would take to write
> a core that's huge because of shared buffers, but perhaps there's some way to
> avoid wr
On Wed, Dec 10, 2014 at 1:37 AM, Fabrízio de Royes Mello
wrote:
> On Tue, Dec 9, 2014 at 10:21 AM, Michael Paquier
> wrote:
>>
>> On Tue, Dec 9, 2014 at 6:43 PM, Michael Paquier
>> wrote:
>> > OK. Perhaps that's not worth mentioning in the release notes, but some
>> > users may be used to the ol
On 12/09/2014 09:41 AM, Alvaro Herrera wrote:
> The first thing where this matters is tuple descriptor expansion in
> parse analysis; at this stage, things such as "*" (in "select *") are
> turned into a target list, which must be sorted according to attlognum.
> To achieve this I added a new routi
On 12/9/14, 4:30 PM, Tom Lane wrote:
Jim Nasby writes:
On 12/9/14, 4:19 PM, Jim Nasby wrote:
Is there any particular reason we don't allow comparing char and varchar
arrays? If not I'll submit a patch.
We're also missing operators on text and varchar arrays.
Adding operators would be an
On 12/9/14, 11:41 AM, Alvaro Herrera wrote:
I'm going to see about it while I get feedback on the rest of this patch; in
particular, extra test cases that fail to work when columns have been
moved around are welcome, so that I can add them to the regress test.
What I have now is the basics I'm bu
* Magnus Hagander (mag...@hagander.net) wrote:
> On Dec 9, 2014 10:52 PM, "Peter Eisentraut" wrote:
> >
> > On 12/5/14 1:06 PM, Stephen Frost wrote:
> > >> I suggest we also backpatch some documentation suggesting that people
> > >> > manually change the include_realm parameter (perhaps also with
On 12/9/14, 4:19 PM, Jim Nasby wrote:
Is there any particular reason we don't allow comparing char and varchar
arrays? If not I'll submit a patch.
We're also missing operators on text and varchar arrays.
--
Jim Nasby, Data Architect, Blue Treble Consulting
Data in Trouble? Get it in Treble! ht
* Peter Eisentraut (pete...@gmx.net) wrote:
> On 12/5/14 1:06 PM, Stephen Frost wrote:
> >> I suggest we also backpatch some documentation suggesting that people
> >> > manually change the include_realm parameter (perhaps also with a note
> >> > saying that the default will change in 9.5).
> > I'll
On 12/8/14, 5:19 PM, Josh Berkus wrote:
On 12/08/2014 02:12 PM, Jim Nasby wrote:
On 12/8/14, 12:26 PM, Josh Berkus wrote:
4. Creation Locking Problem
high probability of lock pile-ups whenever a new partition is created on
demand due to multiple backends trying to create the partition at the
sa
Jim Nasby writes:
> On 12/9/14, 4:19 PM, Jim Nasby wrote:
>> Is there any particular reason we don't allow comparing char and varchar
>> arrays? If not I'll submit a patch.
> We're also missing operators on text and varchar arrays.
Adding operators would be an incorrect fix.
Is there any particular reason we don't allow comparing char and varchar
arrays? If not I'll submit a patch.
--
Jim Nasby, Data Architect, Blue Treble Consulting
Data in Trouble? Get it in Treble! http://BlueTreble.com
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To mak
On Dec 9, 2014 10:52 PM, "Peter Eisentraut" wrote:
>
> On 12/5/14 1:06 PM, Stephen Frost wrote:
> >> I suggest we also backpatch some documentation suggesting that people
> >> > manually change the include_realm parameter (perhaps also with a note
> >> > saying that the default will change in 9.5)
On 12/5/14 1:06 PM, Stephen Frost wrote:
>> I suggest we also backpatch some documentation suggesting that people
>> > manually change the include_realm parameter (perhaps also with a note
>> > saying that the default will change in 9.5).
> I'll work on a patch for back-branches if everyone is alri
On Tue, Dec 9, 2014 at 06:10:02PM -0300, Alvaro Herrera wrote:
> (For pg_upgrade you also need to do something about pg_upgrade_support,
> which is good because that is one very ugly crock.)
FYI, pg_upgrade_support was segregated from pg_upgrade only because we
wanted separate binary and shared o
Alex Shulgin writes:
>
> Bruce Momjian writes:
>>
>> Added to TODO:
>>
>> o Clear table counters on TRUNCATE
>>
>> http://archives.postgresql.org/pgsql-hackers/2008-04/msg00169.php
>
> Hello,
>
> Attached is a WIP patch for this TODO.
This part went as an attachment, which was
Peter Eisentraut wrote:
> Here are the contrib programs:
>
> oid2name
> pg_archivecleanup
> pg_standby
> pg_test_fsync
> pg_test_timing
> pg_upgrade
> pg_xlogdump
> pgbench
> vacuumlo
>
> The proposal would basically be to mv contrib/$x src/bin/$x and also
> move the reference pages in the docum
On Mon, Dec 8, 2014 at 9:31 AM, Robert Haas wrote:
> On Mon, Dec 8, 2014 at 4:56 AM, Heikki Linnakangas
> wrote:
>> I don't immediately see the problem either, but I have to say that
>> grovelling through all the resource owners seems ugly anyway. Resource
>> owners are not meant to be traversed
On 8.12.2014 02:01, Michael Paquier wrote:
> On Sun, Nov 16, 2014 at 3:35 AM, Tomas Vondra wrote:
>> Thanks for the link. I've been looking for a good dataset with such
>> data, and this one is by far the best one.
>>
>> The current version of the patch supports only data types passed by
>> value
On Mon, Dec 8, 2014 at 12:43:36PM -0500, Robert Haas wrote:
> On Sat, Dec 6, 2014 at 10:43 PM, Bruce Momjian wrote:
> > This causes creation DDL is checked if it is used in the regression
> > database, but what about ALTER and DROP? pg_dump doesn't issue those,
> > except in special cases like i
On Mon, Dec 8, 2014 at 10:26 PM, Peter Eisentraut wrote:
> Let's take another crack at moving stuff out of contrib. Nobody likes
> contrib. The task is only finding something that most people like better.
I like contrib fine. It's a great place for things to live that are
not quite baked enoug
> Here are the contrib programs:
>
> oid2name
> pg_archivecleanup
> pg_standby
> pg_test_fsync
> pg_test_timing
> pg_upgrade
> pg_xlogdump
> pgbench
> vacuumlo
>
> The proposal would basically be to mv contrib/$x src/bin/$x and also
> move the reference pages in the documentation.
+1
Consideri
On 12/09/2014 12:17 AM, Amit Langote wrote:
>> Now if user wants to define multi-column Partition based on
>> > monthly_salary and annual_salary, how do we want him to
>> > specify the values. Basically how to distinguish which values
>> > belong to first column key and which one's belong to secon
So I've been updating my very old patch to allow logical and physical
column reordering. Here's a WIP first cut for examination. There are
plenty of rough edges here; most importantly there is no UI at all for
column reordering other than direct UPDATEs of pg_attribute, which most
likely falls af
On Tue, Dec 9, 2014 at 10:21 AM, Michael Paquier
wrote:
>
> On Tue, Dec 9, 2014 at 6:43 PM, Michael Paquier
> wrote:
> > OK. Perhaps that's not worth mentioning in the release notes, but some
> > users may be used to the old behavior. What about the other issues
> > (regression test for permissio
On Tue, Dec 9, 2014 at 11:59 PM, Tom Lane wrote:
> Simon Riggs writes:
>> ISTM that REINDEX is not consistent with VACUUM, ANALYZE or CLUSTER in
>> the way it issues NOTICE messages.
>
>> I'm inclined to simply remove the NOTICE messages, except when a
>> REINDEX ... VERBOSE is requested.
>
> My
Simon Riggs writes:
> ISTM that REINDEX is not consistent with VACUUM, ANALYZE or CLUSTER in
> the way it issues NOTICE messages.
> I'm inclined to simply remove the NOTICE messages, except when a
> REINDEX ... VERBOSE is requested.
My recollection is that those other commands do issue messages
On Mon, Dec 8, 2014 at 9:18 PM, Tom Lane wrote:
> Barring someone committing to spend the time to improve that situation
> (time that would be poorly invested IMO), I don't think that we want to
> open up ignore_system_indexes as USERSET, or do anything else to encourage
> its use.
>
> If we're in
On Tue, Dec 9, 2014 at 12:46 AM, Amit Kapila wrote:
>> I agree with this. For a first version, I think it's OK to start a
>> worker up for a particular sequential scan and have it help with that
>> sequential scan until the scan is completed, and then exit. It should
>> not, as the present versi
Jim Nasby wrote:
> There doesn't seem to be documentation on *= (or search isn't
> finding it). Is this intentional?
http://www.postgresql.org/docs/9.4/static/functions-comparisons.html#COMPOSITE-TYPE-COMPARISON
--
Kevin Grittner
EDB: http://www.enterprisedb.com
The Enterprise PostgreSQL Compan
Bruce Momjian writes:
>
> Added to TODO:
>
> o Clear table counters on TRUNCATE
>
> http://archives.postgresql.org/pgsql-hackers/2008-04/msg00169.php
Hello,
Attached is a WIP patch for this TODO.
>From 97665ef1ca7d1847e90d4dfab38562135f01fb2b Mon Sep 17 00:00:00 2001
From: Ale
Amit Kapila wrote:
> On Tue, Dec 9, 2014 at 1:42 AM, Robert Haas wrote:
> > On Mon, Dec 8, 2014 at 2:56 PM, Andres Freund
> wrote:
> > >> I don't think that's mutually exclusive with the idea of
> > >> partitions-as-tables. I mean, you can add code to the ALTER TABLE
> > >> path that says if (i_
Josh Berkus wrote:
Hi,
> Pardon me for jumping into this late. In general, I like Alvaro's
> approach.
Please don't call this "Alvaro's approach" as I'm not involved in this
anymore. Amit Langote has taken ownership of it now. While some
resemblance to what I originally proposed might remain,
Michael Paquier wrote:
> Hi all,
>
> As mentioned in $subject, we are missing an entry in pg_xlogdump's .gitignore.
Thanks, pushed.
--
Álvaro Herrerahttp://www.2ndQuadrant.com/
PostgreSQL Development, 24x7 Support, Remote DBA, Training & Services
--
Sent via pgsql-hackers mai
On Tue, Dec 9, 2014 at 6:43 PM, Michael Paquier
wrote:
> OK. Perhaps that's not worth mentioning in the release notes, but some
> users may be used to the old behavior. What about the other issues
> (regression test for permissions incorrect and matviews)?
Here is in any case an updated patch to f
Le 08/12/2014 16:18, Tom Lane a écrit :
> Thomas Reiss writes:
>> postgres=# explain select * from test2 where a='toto';
>> QUERY PLAN
>> --
>> Seq Scan on test1 (cost=0.00..1693.00 rows=500 width=5)
>>Filter: ((
On Tue, Dec 9, 2014 at 6:00 PM, Simon Riggs wrote:
> On 9 December 2014 at 17:17, Michael Paquier
> wrote:
>
>>> While re-looking at that. I just found that when selecting the
>>> relations that are reindexed for a schema we ignore materialized view
>>> as the key scan is only done using 'r' as
Simon,
The sample code is here:
https://github.com/kaigai/ctidscan
The code itself and regression tests shows how does it work and
interact with the core backend.
However, its source code comments are not updated and SGML document
is not ready yet, because of my schedule in earlier half of Dec
On Tuesday, December 9, 2014, Simon Riggs wrote:
> On 9 December 2014 at 17:17, Michael Paquier > wrote:
>
> >> While re-looking at that. I just found that when selecting the
> >> relations that are reindexed for a schema we ignore materialized view
> >> as the key scan is only done using 'r' as
On 9 December 2014 at 17:17, Michael Paquier wrote:
>> While re-looking at that. I just found that when selecting the
>> relations that are reindexed for a schema we ignore materialized view
>> as the key scan is only done using 'r' as relkind. The patch attached
>> fixes that.
> Here is an updat
On Tue, Nov 11, 2014 at 3:00 PM, Andres Freund
wrote:
> On 2014-11-11 09:29:22 +, Thom Brown wrote:
> > On 26 September 2014 12:40, Amit Kapila wrote:
> >
> > > On Tue, Sep 23, 2014 at 10:31 AM, Robert Haas
> > > wrote:
> > > >
> > > > But this gets at another point: the way we're benchmark
On Tue, Dec 9, 2014 at 12:59 PM, Amit Kapila wrote:
> On Tue, Dec 9, 2014 at 8:08 AM, Amit Langote
> wrote:
>> > From: Robert Haas [mailto:robertmh...@gmail.com]
>> > On Sat, Dec 6, 2014 at 2:59 AM, Amit Kapila
>> > wrote:
>> > >> I guess you could list or hash partition on multiple columns, t
On 7 December 2014 at 08:21, Kouhei Kaigai wrote:
> Please wait for a few days. The ctidscan module is not adjusted for the
> latest interface yet.
I am in many ways a patient man. At this point it is 12 days since my
request for a working example.
Feedback I am receiving is that the API is unu
Hi all,
As mentioned in $subject, we are missing an entry in pg_xlogdump's .gitignore.
Patch attached.
Regards,
--
Michael
diff --git a/contrib/pg_xlogdump/.gitignore b/contrib/pg_xlogdump/.gitignore
index 37974e0..16cf749 100644
--- a/contrib/pg_xlogdump/.gitignore
+++ b/contrib/pg_xlogdump/.git
On Tue, Dec 9, 2014 at 4:44 PM, Michael Paquier
wrote:
> On Tue, Dec 9, 2014 at 10:10 AM, Michael Paquier
> wrote:
>> On Tue, Dec 2, 2014 at 3:42 PM, Michael Paquier
>> wrote:
>>> Adding on top of that a couple of things cleaned up, like docs and
>>> typos, and I got the patch attached. Let's ha
60 matches
Mail list logo
