Robert Haas writes:
> I think that might be acceptable from a performance point of view -
> after all, if the index is unlogged, you're saving the cost of WAL -
> but I guess I still prefer a generic solution to this problem (a
> generalization of GetXLogRecPtrForTemp) rather than a special-purpos
On Tue, Jan 15, 2013 at 12:13 AM, wrote:
> The following bug has been logged on the website:
>
> Bug reference: 7809
> Logged by: Joe Van Dyk
> Email address: j...@tanga.com
> PostgreSQL version: 9.2.2
> Operating system: Ubuntu
> Description:
>
> Running pg_dump on a streami
On Jan 15, 2013, at 12:17 PM, Andrew Dunstan wrote:
> I doubt I'm very representative either. People like David Wheeler, Taras
> Mitran, Joe Van Dyk, and the Heroku guys would be better people to ask than
> me. I'm quite prepared to change it if that's the consensus.
They’re JSON arrays, not S
On 16/01/13 08:04, David Fetter wrote:
On Mon, Jan 14, 2013 at 07:52:56PM -0500, Andrew Dunstan wrote:
On 01/14/2013 07:36 PM, Merlin Moncure wrote:
While testing this I noticed that integer based 'get' routines are
zero based -- was this intentional? Virtually all other aspects of
SQL are 1 b
Stephen Frost writes:
> * Bruce Momjian (br...@momjian.us) wrote:
>> And this leads to support-my-compression-binary-of-the-day mess. Why
>> not just allow them to do '|compression-binary'?
> The popen patch doesn't support the '|compression-binary' option through
> the FE protocol. Even if it
On Tue, Jan 15, 2013 at 4:26 PM, Tom Lane wrote:
> Robert Haas writes:
>> I think that might be acceptable from a performance point of view -
>> after all, if the index is unlogged, you're saving the cost of WAL -
>> but I guess I still prefer a generic solution to this problem (a
>> generalizati
I mentioned last year that I wanted to start working on parallelism:
https://wiki.postgresql.org/wiki/Parallel_Query_Execution
Years ago I added thread-safety to libpq. Recently I added two parallel
execution paths to pg_upgrade. The first parallel path allows execution
of external bina
* Tom Lane (t...@sss.pgh.pa.us) wrote:
> I find the argument that this supports compression-over-the-wire to be
> quite weak, because COPY is only one form of bulk data transfer, and
> one that a lot of applications don't ever use. If we think we need to
> support transmission compression for ours
On Tue, Jan 15, 2013 at 04:22:48PM -0500, Stephen Frost wrote:
> * Bruce Momjian (br...@momjian.us) wrote:
> > Well, COPY is super-user only, so it seems only useful for FDW, no? We
> > already have lots of user-configuration FDW commands, so I can see
> > adding this one too.
>
> COPY is most ce
* Bruce Momjian (br...@momjian.us) wrote:
> COPY with a file name is super-user-only. I am unclear how you would
> use STDIN/STDOUT in any meaningful way with binary data produced by
> compression. I guess you could with libpq.
The patch that I posted provided this:
psql -h myhost -c "COPY myta
On 2013-01-15 14:40:11 -0500, Tom Lane wrote:
> Sergey Koposov writes:
> > And I do see the tblspc file left after the finish of "make check":
> > tmp_check/data/pg_tblspc/16385/PG_9.3_201212081/16384/16387
>
> Interesting. If the tests are run immediately after initdb, 16387
> is the relfil
* Bruce Momjian (br...@momjian.us) wrote:
> Parallelism isn't going to help all queries, in fact it might be just a
> small subset, but it will be the larger queries. The pg_upgrade
> parallelism only helps clusters with multiple databases or tablespaces,
> but the improvements are significant.
T
On 15 January 2013 22:14, Bruce Momjian wrote:
> I believe it is time to start adding parallel execution to the backend.
> We already have some parallelism in the backend:
> effective_io_concurrency and helper processes. I think it is time we
> start to consider additional options.
A few months
On Tue, Jan 15, 2013 at 10:39:10PM +, Peter Geoghegan wrote:
> On 15 January 2013 22:14, Bruce Momjian wrote:
> > I believe it is time to start adding parallel execution to the backend.
> > We already have some parallelism in the backend:
> > effective_io_concurrency and helper processes. I t
Stephen Frost writes:
> * Tom Lane (t...@sss.pgh.pa.us) wrote:
>> I find the argument that this supports compression-over-the-wire to be
>> quite weak, because COPY is only one form of bulk data transfer, and
>> one that a lot of applications don't ever use. If we think we need to
>> support tran
On Tue, Jan 15, 2013 at 10:53:29PM +, Simon Riggs wrote:
> On 15 January 2013 22:14, Bruce Momjian wrote:
>
> > I mentioned last year that I wanted to start working on parallelism:
>
> We don't normally begin discussing topics for next release just as a
> CF is starting.
>
> Why is this bei
On 15 January 2013 22:14, Bruce Momjian wrote:
> I mentioned last year that I wanted to start working on parallelism:
We don't normally begin discussing topics for next release just as a
CF is starting.
Why is this being discussed now?
--
Simon Riggs http://www.2ndQuadrant.
Andres Freund writes:
> I played a bit arround (thanks Sergey!) and it seems to be some rather
> strange optimization issue around the fsync request queue.
> Namely changing
> request->rnode = rnode;
> into
> request->rnode.spcNode = rnode.spcNode;
> request->rnode.dbNode = rno
On 15 January 2013 22:55, Bruce Momjian wrote:
>> Why is this being discussed now?
>
> It is for 9.4 and will take months. I didn't think there was a better
> time. We don't usually discuss features during beta testing.
Bruce, there are many, many patches on the queue. How will we ever get
to
On 16/01/13 11:14, Bruce Momjian wrote:
I mentioned last year that I wanted to start working on parallelism:
https://wiki.postgresql.org/wiki/Parallel_Query_Execution
Years ago I added thread-safety to libpq. Recently I added two parallel
execution paths to pg_upgrade. The first paral
On Tue, Jan 15, 2013 at 11:01:04PM +, Simon Riggs wrote:
> On 15 January 2013 22:55, Bruce Momjian wrote:
>
> >> Why is this being discussed now?
> >
> > It is for 9.4 and will take months. I didn't think there was a better
> > time. We don't usually discuss features during beta testing.
>
* Tom Lane (t...@sss.pgh.pa.us) wrote:
> Really? Given that libpq provides no useful support for doing anything
> with COPY data, much less higher-level packages such as Perl DBI, I'd
> venture that the real-world ratio is more like 90/10. If not 99/1.
Perhaps I'm taking a bit too narrow view of
On Wed, Jan 16, 2013 at 12:03:50PM +1300, Gavin Flower wrote:
> On 16/01/13 11:14, Bruce Momjian wrote:
>
> I mentioned last year that I wanted to start working on parallelism:
>
> https://wiki.postgresql.org/wiki/Parallel_Query_Execution
>
> Years ago I added thread-safety t
* Gavin Flower (gavinflo...@archidevsys.co.nz) wrote:
> How about being aware of multiple spindles - so if the requested
> data covers multiple spindles, then data could be extracted in
> parallel. This may, or may not, involve multiple I/O channels?
Yes, this should dovetail with partitioning and
Stephen Frost writes:
> * Tom Lane (t...@sss.pgh.pa.us) wrote:
>> Really? Given that libpq provides no useful support for doing anything
>> with COPY data, much less higher-level packages such as Perl DBI, I'd
>> venture that the real-world ratio is more like 90/10. If not 99/1.
> Perhaps I'm t
On Tue, Jan 15, 2013 at 06:15:57PM -0500, Stephen Frost wrote:
> * Gavin Flower (gavinflo...@archidevsys.co.nz) wrote:
> > How about being aware of multiple spindles - so if the requested
> > data covers multiple spindles, then data could be extracted in
> > parallel. This may, or may not, involve
Stephen Frost writes:
> Perhaps I'm taking a bit too narrow view of the world, but my thinking
> is OLTP won't want things compressed, as it increases latency of
> requests, while OLAP users are operating with enough data that they'll
> go through the effort to use COPY.
Also, if there are so man
On 2013-01-15 17:56:40 -0500, Tom Lane wrote:
> Andres Freund writes:
> > I played a bit arround (thanks Sergey!) and it seems to be some rather
> > strange optimization issue around the fsync request queue.
>
> > Namely changing
> > request->rnode = rnode;
> > into
> > request->rnode.sp
On 01/15/2013 06:22 PM, Tom Lane wrote:
Stephen Frost writes:
Perhaps I'm taking a bit too narrow view of the world, but my thinking
is OLTP won't want things compressed, as it increases latency of
requests, while OLAP users are operating with enough data that they'll
go through the effort to
On Wed, Jan 16, 2013 at 4:29 AM, Bruce Momjian wrote:
> That's Japanese for idempotent. ;-) LOL
>
+1.
--
Michael Paquier
http://michael.otacoo.com
Peter Eisentraut writes:
> I'll take another stab at providing pkg-config files for the client-side
> libraries.
This bit:
> + echo 'Libs.private: $(filter-out
> $(PKG_CONFIG_REQUIRES_PRIVATE:lib%=-l%),$(filter-out -L..%, $(SHLIB_LINK)))'
> >>$@
appears to assume that SHLIB_LINK contains
Hello all,
We've been seeing these same messages flying by our logs for years:
2012-12-13 22:28:07 GMT LOG: picksplit method for column 2 of index
"xxx_idx" doesn't support secondary split
I see from the linked message that Tom Lane made the recommendation of changing
the loglevel
On 2013-01-16 00:26:01 +0100, Andres Freund wrote:
> On 2013-01-15 17:56:40 -0500, Tom Lane wrote:
> > Andres Freund writes:
> > > I played a bit arround (thanks Sergey!) and it seems to be some rather
> > > strange optimization issue around the fsync request queue.
> >
> > > Namely changing
> >
On Wed, Jan 16, 2013 at 7:14 AM, Bruce Momjian wrote:
> I mentioned last year that I wanted to start working on parallelism:
>
> https://wiki.postgresql.org/wiki/Parallel_Query_Execution
>
> Years ago I added thread-safety to libpq. Recently I added two parallel
> execution paths to pg_u
First rev of a simple corruption program is attached, in very C-ish
Python. The parameters I settled on are to accept a relation name, byte
offset, byte value, and what sort of operation to do: overwrite, AND,
OR, XOR. I like XOR here because you can fix it just by running the
program again.
Andres Freund writes:
> FWIW its also triggerable if two other function calls are places inside
> the above if() (I tried fprintf(stderr, "argh") and kill(0, 0)).
[ confused... ] You mean replacing the abort() in the elog macro with
one of these functions? Or something else?
> It seems the cha
On 2013-01-15 19:56:52 -0500, Tom Lane wrote:
> Andres Freund writes:
> > FWIW its also triggerable if two other function calls are places inside
> > the above if() (I tried fprintf(stderr, "argh") and kill(0, 0)).
>
> [ confused... ] You mean replacing the abort() in the elog macro with
> one o
Andres Freund writes:
> On 2013-01-15 19:56:52 -0500, Tom Lane wrote:
>> At this point I'm more interested in his report in
>> about
>> the Assert at spgdoinsert.c:1222 failing. That's pretty new code, so
>> more likely to have a genuine bug, and I wonder if it's related to
>> the spgist issue i
On 2013-01-16 02:13:26 +0100, Andres Freund wrote:
> On 2013-01-15 19:56:52 -0500, Tom Lane wrote:
> > Andres Freund writes:
> > > FWIW its also triggerable if two other function calls are places inside
> > > the above if() (I tried fprintf(stderr, "argh") and kill(0, 0)).
> >
> > [ confused... ]
On Sun, Oct 14, 2012 at 8:53 PM, Josh Kupershmidt
>
wrote:
> Hi all,
> It seems the queries in ./src/tutorial/syscat.source use string
> escaping with the assumption that standard_conforming_strings is off,
> and thus give wrong results with modern versions. A simple fix is
> attached.
Hi Josh,
D
On 2013-01-15 20:32:00 -0500, Tom Lane wrote:
> Andres Freund writes:
> > On 2013-01-15 19:56:52 -0500, Tom Lane wrote:
> >> At this point I'm more interested in his report in
> >> about
> >> the Assert at spgdoinsert.c:1222 failing. That's pretty new code, so
> >> more likely to have a genuine
On 2013-01-16 02:34:52 +0100, Andres Freund wrote:
> On 2013-01-16 02:13:26 +0100, Andres Freund wrote:
> > On 2013-01-15 19:56:52 -0500, Tom Lane wrote:
> > > Andres Freund writes:
> > > > FWIW its also triggerable if two other function calls are places inside
> > > > the above if() (I tried fpri
Andres Freund writes:
> -O0 passes
Grumble... suspect we're chasing another compiler bug now, but ...
You might try -O1; if that shows the bug it'll probably be a tad easier
to debug in.
regards, tom lane
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresq
On Wed, Jan 16, 2013 at 09:11:20AM +0900, Michael Paquier wrote:
>
>
> On Wed, Jan 16, 2013 at 7:14 AM, Bruce Momjian wrote:
>
> I mentioned last year that I wanted to start working on parallelism:
>
> https://wiki.postgresql.org/wiki/Parallel_Query_Execution
>
> Years ago
On Tue, Jan 15, 2013 at 8:19 PM, Bruce Momjian wrote:
>> Given our row-based storage architecture, I can't imagine we'd do
>> anything other than take a row-based approach to this.. I would think
>> we'd do two things: parallelize based on partitioning, and parallelize
>> seqscan's across the ind
When there is contention between concurrent transactions it shows up
as with log_lock_waits as
LOG: process %d acquired %s on %s transaction %u after %ld.%03d ms
Which is mostly useless for identifying and eliminating the contention
in the application since you can't tell which table is causin
On Tue, Jan 15, 2013 at 7:46 PM, Tom Lane wrote:
>> Compressing every small packet seems like it'd be overkill and might
>> surprise people by actually reducing performance in the case of lots of
>> small requests.
>
> Yeah, proper selection and integration of a compression method would be
> criti
S X behave like other
platforms in this regard. There might be other portability issues on
other platforms.
pg-transforms-20130115.patch.gz
Description: GNU Zip compressed data
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www
* Claudio Freire (klaussfre...@gmail.com) wrote:
> On Tue, Jan 15, 2013 at 8:19 PM, Bruce Momjian wrote:
> > The 1GB idea is interesting. I found in pg_upgrade that file copy would
> > just overwhelm the I/O channel, and that doing multiple copies on the
> > same device had no win, but those were
On Wed, Jan 16, 2013 at 12:13 AM, Stephen Frost wrote:
> * Claudio Freire (klaussfre...@gmail.com) wrote:
>> On Tue, Jan 15, 2013 at 8:19 PM, Bruce Momjian wrote:
>> > The 1GB idea is interesting. I found in pg_upgrade that file copy would
>> > just overwhelm the I/O channel, and that doing mult
Simon,
* Simon Riggs (si...@2ndquadrant.com) wrote:
> Attached patch passes through further information about the lock wait,
> so we can display the following message instead
>LOG: process %d acquired %s on transaction %u on relation %u of
> database %u after %ld.%03d ms
I love this idea. Pl
* Claudio Freire (klaussfre...@gmail.com) wrote:
> On Wed, Jan 16, 2013 at 12:13 AM, Stephen Frost wrote:
> > Sequentially scanning the *same* data over and over is certainly
> > counterprouctive. Synchroscans fixed that, yes. That's not what we're
> > talking about though- we're talking about s
>> but there will be
>> quite a few cases where it's much, much better.
>
> Just cached segments.
Actually, thanks to much faster storage (think SSD, SAN), it's easily
possible for PostgreSQL to become CPU-limited on a seq scan query, even
when reading from disk.
--
Josh Berkus
PostgreSQL Expe
* Josh Berkus (j...@agliodbs.com) wrote:
> Actually, thanks to much faster storage (think SSD, SAN), it's easily
> possible for PostgreSQL to become CPU-limited on a seq scan query, even
> when reading from disk.
Particularly with a complex filter being applied or if it's feeding into
something ab
Claudio, Stephen,
It really seems like the areas where we could get the most "bang for the
buck" in parallelism would be:
1. Parallel sort
2. Parallel aggregation (for commutative aggregates)
3. Parallel nested loop join (especially for expression joins, like GIS)
--
Josh Berkus
PostgreSQL Exp
On Wed, Jan 16, 2013 at 1:22 PM, Josh Berkus wrote:
> Claudio, Stephen,
>
> It really seems like the areas where we could get the most "bang for the
> buck" in parallelism would be:
>
> 1. Parallel sort
> 2. Parallel aggregation (for commutative aggregates)
> 3. Parallel nested loop join (especia
On Wed, Jan 16, 2013 at 01:28:18PM +0900, Michael Paquier wrote:
>
>
> On Wed, Jan 16, 2013 at 1:22 PM, Josh Berkus wrote:
>
> Claudio, Stephen,
>
> It really seems like the areas where we could get the most "bang for the
> buck" in parallelism would be:
>
> 1. Parallel sort
>
On Wed, Jan 16, 2013 at 1:32 PM, Bruce Momjian wrote:
> On Wed, Jan 16, 2013 at 01:28:18PM +0900, Michael Paquier wrote:
> >
> >
> > On Wed, Jan 16, 2013 at 1:22 PM, Josh Berkus wrote:
> >
> > Claudio, Stephen,
> >
> > It really seems like the areas where we could get the most "bang for
On Wed, Jan 16, 2013 at 12:55 AM, Stephen Frost wrote:
>> If memory serves me correctly (and it does, I suffered it a lot), the
>> performance hit is quite considerable. Enough to make it "a lot worse"
>> rather than "not as good".
>
> I feel like we must not be communicating very well.
>
> If the
Bruce Momjian escribió:
> On Wed, Jan 16, 2013 at 01:28:18PM +0900, Michael Paquier wrote:
> >
> >
> > On Wed, Jan 16, 2013 at 1:22 PM, Josh Berkus wrote:
> >
> > Claudio, Stephen,
> >
> > It really seems like the areas where we could get the most "bang for the
> > buck" in paralle
On Tue, Jan 15, 2013 at 6:35 PM, Jeff Janes wrote:
> Do you propose back-patching this? You could argue that this is a bug in
> 9.1 and 9.2. Before that, they generate deprecation warnings, but do not
> give the wrong answer.
I think that backpatching to 9.1 would be reasonable, though I won'
On Tuesday, January 15, 2013, Simon Riggs wrote:
> On 15 January 2013 22:55, Bruce Momjian >
> wrote:
>
> >> Why is this being discussed now?
> >
> > It is for 9.4 and will take months. I didn't think there was a better
> > time. We don't usually discuss features during beta testing.
>
> Bruce,
On Wed, Jan 9, 2013 at 6:42 AM, Gurjeet Singh wrote:
>
>>
> I have updated the commitfest submission to link to the correct patch
> email.
>
>
Thanks Gurjeet.
> I initially thought that this patch deserves accompanying documentation
> because pg_dump's serializable transaction may error out beca
It's a compiler bug.
icc 11.1 apparently thinks that this loop in doPickSplit:
/*
* Update nodes[] array to point into the newly formed innerTuple, so that
* we can adjust their downlinks below.
*/
SGITITERATE(innerTuple, i, node)
{
nodes[i] = node;
}
is go
Alvaro Herrera writes:
> There are still 34 items needing attention in CF3. I suggest that, if
> you have some spare time, your help would be very much appreciated
> there. The commitfest that started on Jan 15th has 65 extra items.
> Anything currently listed in CF3 can rightfully be considered
Hi.
This patch was marked "Needs review" with no reviewers in the ongoing
CF, so I decided to take a look at it. I see that Zoltan has posted a
review, so I've added him to the list.
But I took a look at the latest patch in any case. Here are some
comments, mostly cosmetic ones.
> diff -dcrpN po
101 - 166 of 166 matches
Mail list logo
