g I’d want it within my network to be discoverable via
Bonjour…
Given these issues I’d recommend disabling the functionality for non-Mac until
someone can get a workable solution in place – then at least it will avoid
people like me trying to enable a broken feature and failing…
- Luke
compatibility library
- Luke
On 11/8/17, 3:00 PM, "Tom Lane" wrote:
BTW, when I try this on Fedora 25, it builds cleanly but the feature
doesn't seem to work --- I get this at postmaster start:
I wonder which libdns_sd you are using.
Hi Tom – works for me on Linux (Ubuntu)…
- Luke
*** /home/llonergan/archive/configure.in2017-11-08 14:17:56.804891827
-0800
--- configure.in2017-11-08 14:15:58.961186149 -0800
***
*** 1293,1298
--- 1293,1299
if test
eRefSockFD, [], [AC_MSG_ERROR([library
'dns_sd' is required for Bonjour])])
fi
# for contrib/uuid-ossp
- Luke
t about 12 MB/s of heap insertion rate per CPU core and it's
CPU bound.
You can peek in on what's happening using gstack on Linux, or the gdb
"attach and print stacktrace" approach for a crude profile.
- Luke
On 2/19/08 1:36 PM, "Joshua D. Drake" <[EMAIL PROTECTE
All
Is there an interest in developing bitemporal functionality in PostgreSQL
Regards
Luke > From: [EMAIL PROTECTED]> Subject: Re: bitemporal functionality for
PostgreSQL> To: [EMAIL PROTECTED]> Date: Fri, 1 Feb 2008 10:08:03 -0500> > Luke
Porter wrote:> > &
Vacuum is a better thing to run, much less CPU usage.
- Luke
Msg is shrt cuz m on ma treo
-Original Message-
From: Greg Smith [mailto:[EMAIL PROTECTED]
Sent: Monday, November 12, 2007 11:59 PM Eastern Standard Time
To: Alex Drobychev
Cc: pgsql-hackers@postgresql.org
Subject
ache locality. Tight loops will make a much bigger
difference when long runs of data are the target operands.
- Luke
---(end of broadcast)---
TIP 7: You can help support the PostgreSQL project by donating at
http://www.postgresql.org/about/donate
gnal
(SIGUSR maybe?) and that would cause an update to the table? That way we'd
have the desired feature that the tracking isn't continuous, it's based on a
"peek" approach, which is only as obtrusive as needed.
- Luke
---(end of broadcast)-
rently. I think pstack uses dtrace underneath the hood...
- Luke
On 9/25/07 3:00 AM, "Mark Wong" <[EMAIL PROTECTED]> wrote:
> Hi everyone,
>
> I was playing with converting unixtop (the version of top used in
> FreeBSD) to only show PostgreSQL processes pulled from the
Index organized tables would do this and it would be a generic capability.
- Luke
Msg is shrt cuz m on ma treo
-Original Message-
From: Georgi Chulkov [mailto:[EMAIL PROTECTED]
Sent: Monday, September 17, 2007 11:50 PM Eastern Standard Time
To: Tom Lane
Cc: pgsql-hackers
Below is a patch against Greenplum Database that fixes the problem.
- Luke
-- Forwarded Message
From: Luke Lonergan <[EMAIL PROTECTED]>
Date: Fri, 24 Aug 2007 09:25:53 -0700
To: Heikki Linnakangas <[EMAIL PROTECTED]>, Anton <[EMAIL PROTECTED]>
Cc: <[EMAIL PROTECTED]>
All - we have customers who very much want tsearch2 and will benefit from its
inclusion in core.
We are also struggling with the update trigger approach for various reasons.
Is there a good alternative? Can we embed tsvector updates into the core code
efficiently?
- Luke
Msg is shrt cuz m
A hybrid scan approach combined with this idea would fit nicely - provide
results for tids that are directly visible and set a bit in a bitmap for those
that need recheck and extend recheck to take a bitmap (wait - it already does
:-)
- Luke
Msg is shrt cuz m on ma treo
-Original
With (1), we just have to define the meaning of "concurrent" to be "within
the span of the OS I/O cache" and we're describing the same effect.
- Luke
---(end of broadcast)---
TIP 7: You can help support the PostgreSQL project by donating at
http://www.postgresql.org/about/donate
/O cache with useful blocks. This will
require some knowledge of the size of the I/O cache by the syncscan logic,
but that's where the largest amount of I/O cache memory (by far) is located.
- Luke
On 5/15/07 3:34 PM, "Jim C. Nasby" <[EMAIL PROTECTED]> wrote:
> On Tu
Heikki,
32 buffers = 1MB with 32KB blocksize, which spoils the CPU L2 cache
effect.
How about using 256/blocksize?
- Luke
> -Original Message-
> From: Heikki Linnakangas [mailto:[EMAIL PROTECTED] On
> Behalf Of Heikki Linnakangas
> Sent: Tuesday, May 15, 2007 2:32 AM
>
nificant.
COPY is bottlenecked on datum formation and format translation with very low
performance, so I don't think we should expect the ring buffer to make much
of a dent.
- Luke
---(end of broadcast)---
TIP 7: You can help
> advantage of pages already in buffer cache) strategy at all,
> and want the buffer ring strategy to kick in earlier instead.
> Am I reading you correctly?
Yes, I think the ring buffer strategy should be used when the table size
is > 1 x bufcache and the ring buffer should be of a
x bufcache
- for tables > 1 x bufcache use a ringbuffer for I/O that is ~ 32KB to
minimize L2 cache pollution
- Luke
> -Original Message-
> From: [EMAIL PROTECTED]
> [mailto:[EMAIL PROTECTED] On Behalf Of
> Heikki Linnakangas
> Sent: Tuesday, May 08, 2007 3:40 AM
>
amples there include the segmentation of fixed width types and
variable width types into separate page storage classes, which allows for
the application of different compression and/or representations on pages.
- Luke
---(end of broadcast)
Hi Bruce,
On 4/12/07 9:24 AM, "Bruce Momjian" <[EMAIL PROTECTED]> wrote:
> Luke Lonergan wrote:
>> Hi Bruce,
>>
>> How about these:
>>
>> - Allow specification of TOAST size threshold in bytes on a per column basis
>> - Enable storage
Hi Bruce,
How about these:
- Allow specification of TOAST size threshold in bytes on a per column basis
- Enable storage of columns in separate TOAST tables
- Enable use of multi-row compression method(s) for TOAST tables
- Luke
On 3/26/07 5:39 PM, "Bruce Momjian" <[EMAIL PROT
Not just EDB :-)
- Luke
Msg is shrt cuz m on ma treo
-Original Message-
From: Chris Browne [mailto:[EMAIL PROTECTED]
Sent: Wednesday, April 04, 2007 10:07 PM Eastern Standard Time
To: pgsql-hackers@postgresql.org
Subject:Re: [HACKERS] Modifying TOAST thresholds
[EMAIL
if they made changes to the
agreement. In any case, I'm not sure what this really means.
Perhaps someone from OIN can enlighten us.
- Luke
---(end of broadcast)---
TIP 3: Have you checked our extensive FAQ?
http://www.postgresql.org/docs/faq
to also support further development along the vertical
partitioning path. Any thought on support of per-column TOAST tables?
- Luke
---(end of broadcast)---
TIP 1: if posting/reading through Usenet, please send an appropriate
subscribe-nomail
Jeff,
Your conclusions sound great - can you perhaps put the timings in a column
in your table so we can confirm them?
- Luke
On 4/2/07 4:14 PM, "Jeff Davis" <[EMAIL PROTECTED]> wrote:
> I posted some fairly detailed benchmark results for my Synchronized Scan
> patch
This may have the nice side effect of pushing 'possibly patented' technologies
into the FOSS realm, but again I wonder what the duration/persistence of
Oracle's committment is?
I think I will ask our lawyers to review this.
- Luke
Msg is shrt cuz m on ma treo
-Original Me
Bruce,
This is big news - has anyone checked to see if the agreement for the OIN is
in perpetuity? Or is their agreement to not pursue patents only for as long
as they are members?
- Luke
On 3/30/07 10:43 AM, "Bruce Momjian" <[EMAIL PROTECTED]> wrote:
> Here is a surprisin
"vectorization", not the operator
de-abstraction IMO, which is good news for us all.
- Luke
---(end of broadcast)---
TIP 5: don't forget to increase your free space map settings
at's already in
Postgres as baby steps toward more advanced features.
- Luke
---(end of broadcast)---
TIP 9: In versions below 8.0, the planner will ignore your desire to
choose an index scan if your joining column's datatypes do not
match
a columns,
compression and encryption approaches that use column packed data are much
more effective.
As Tom points out there are complications WRT update, access, etc that need
to be worked out to support this, but it's an important capability to have
IMO.
- Luke
--
I advocate the following:
- Enable specification of TOAST policy on a per column basis
As a first step, then:
- Enable vertical partitioning of tables using per-column specification of
storage policy.
- Luke
On 3/21/07 1:12 PM, "Bruce Momjian" <[EMAIL PROTECTED]> wrote:
>
Wow, nice!
Can you tell us:
- how big is the table
- cardinality of the column
- how big is the index in each case
- how much memory on the machine
- query and explain analyze
Thanks!
- Luke
Msg is shrt cuz m on ma treo
-Original Message-
From: Grzegorz Jaskiewicz [mailto:[EMAIL
m, but it may take a week to get some early results and
find out if we're on the right track. We've been wrong on this before ;-)
- Luke
---(end of broadcast)---
TIP 2: Don't 'kill -9' the postmaster
fers cache.
The hypothesis is that if a relation is of a size equal to or less than the
size of shared_buffers, it is "cacheable" and should use the standard LRU
approach to provide for reuse.
- Luke
On 3/12/07 3:08 AM, "Simon Riggs" <[EMAIL PROTECTED]> wrote:
> On Mon,
.
Somewhere in that progression we'll learn more about how the multi-level
buffering really works. I think we'll get all the shared I/O cache we need.
- Luke
---(end of broadcast)---
TIP 2: Don't 'kill -9' the postmaster
Cool!
- Luke
Msg is shrt cuz m on ma treo
-Original Message-
From: Simon Riggs [mailto:[EMAIL PROTECTED]
Sent: Friday, March 09, 2007 02:32 PM Eastern Standard Time
To: Luke Lonergan; ITAGAKI Takahiro
Cc: Sherry Moore; Tom Lane; Mark Kirkwood; Pavan Deolasee; Gavin Sherry
Simon,
What happens to the data when the function is dropped or replaced?
- Luke
Msg is shrt cuz m on ma treo
-Original Message-
From: Simon Riggs [mailto:[EMAIL PROTECTED]
Sent: Friday, March 09, 2007 06:20 AM Eastern Standard Time
To: NikhilS
Cc: Shane Ambler; Luke
how many disks are in an array,
while the sequential scales nearly linearly with the number of drives in the
array.
So, you can estimate random using 8-12ms per random access, and sequential as
1/(number of disks X 60-130MB/s).
Ayush, can you forward your C program?
- Luke
Msg is shrt cuz m
during
> runtime), but imho the approach is very good.
Well, it's being used and that's good, but it needs to be better IMO and I
think that before we go too far down the current path we should consider the
alternatives more carefully.
- Luke
---(end of
Yep - we're paying attention Josh!
I like the category being explored with skyline, I'm not sure yet how it fits
with existing 'soft data' models and applications that use them.
If SKYLINE is interesting to app developers, maybe we should consider it for
Bizgres?
- Luke
a compressed data stream, of course. :-
We handle that by doing a recompression in page if possibly, page splitting
if not.
Jie/Gavin's work will initially be an equality encoded bitmap as Heikki
indicates, soon after we can implement range encoding, etc.
- Luke
logN) operation.
I think we need to re-evaluate the inheritance mechanism for partitioning
and implement something much closer to the storage layer, similar to Oracle.
Having the constraint exclusion occur in the planner is not flexible enough
to allow more advanced solutions.
- Luke
-
+1
On 3/7/07 6:53 AM, "Grzegorz Jaskiewicz" <[EMAIL PROTECTED]> wrote:
> my only question would be.
> Why isn't that in core already ?
>
> ---(end of broadcast)---
> TIP 9: In versions below 8.0, the planner will ignore your desire to
>cho
the higher data rates due to this
effect.
- Luke
Msg is shrt cuz m on ma treo
-Original Message-
From: Sherry Moore [mailto:[EMAIL PROTECTED]
Sent: Tuesday, March 06, 2007 10:05 PM Eastern Standard Time
To: Simon Riggs
Cc: Sherry Moore; Tom Lane; Luke Lonergan; Mark Kirkwood
he NTA instruction when
appropriate.
We can handle syncscan using a small buffer space.
- Luke
---(end of broadcast)---
TIP 2: Don't 'kill -9' the postmaster
Hi Tom,
Good info - it's the same in Solaris, the routine is uiomove (Sherry wrote it).
- Luke
Msg is shrt cuz m on ma treo
-Original Message-
From: Tom Lane [mailto:[EMAIL PROTECTED]
Sent: Monday, March 05, 2007 07:43 PM Eastern Standard Time
To: Mark Kirkwood
Cc:
This sounds like a good idea.
- Luke
Msg is shrt cuz m on ma treo
-Original Message-
From: Simon Riggs [mailto:[EMAIL PROTECTED]
Sent: Monday, March 05, 2007 02:37 PM Eastern Standard Time
To: Josh Berkus; Tom Lane; Pavan Deolasee; Mark Kirkwood; Gavin Sherry;
Luke Lonergan
4.12
18680 5.834.10
28016 6.114.46
WRT what you found on the selection algorithm, it might also explain the L2
effects I think.
I'm also still of the opinion that polluting the shared buffer cache for a
seq scan does not make sense.
- Luke
On 3/5/07
of these were run three times and the *lowest* time reported. Also, the
behavior of "fast VACUUM after SELECT" begins abruptly at 1232KB of
shared_buffers.
These are Opterons with 2MB of L2 cache shared between two cores.
- Luke
---(end of broadcast)---
TIP 6: explain analyze is your friend
Hi Tom,
On 3/5/07 8:53 AM, "Tom Lane" <[EMAIL PROTECTED]> wrote:
> Hm, that seems to blow the "it's an L2 cache effect" theory out of the
> water. If it were a cache effect then there should be a performance
> cliff at the point where the cache size is exceeded. I see no such
> cliff, in fact t
n)famous dd test, so we have a bit of headroom (not too bad
> for a PIII).
What's really interesting: try this with a table that fits into I/O
cache (say half your system memory), and run VACUUM on the table. That
way the effect will stand out more dramatically.
- Luke
--
2 lines are stored into, and the write to main memory
is delayed under the assumption that these lines are "hot" as they were
already in L2.
I don't know enough to be sure this is the right answer, but it does fit
the experimental data.
- Luke
---(end of broadcast)---
TIP 4: Have you searched our list archives?
http://archives.postgresql.org
the blocks are filling the entire shared
buffer cache. This should be "fixed".
My proposal for a fix: ensure that when relations larger (much larger?)
than buffer cache are scanned, they are mapped to a single page in the
shared buffer cache.
- Luke
---
we're seeing the
buffer cache pollution in the first place. When we instrument the
blocks selected by the buffer page selection algorithm, we see that they
iterate sequentially, filling the shared buffer cache. That's the
source of the problem here.
Do we have a regressio
pe/white_papers_and_tech_docs/
25112.PDF
- Luke
---(end of broadcast)---
TIP 6: explain analyze is your friend
larger than the buffer size
- Luke
---(end of broadcast)---
TIP 4: Have you searched our list archives?
http://archives.postgresql.org
One more thing: the L2 is invalidated when re-written from the kernel IO cache,
but the pages addressed in L2 retain their values when 'writeen thru' which
allows the new data to be re-used up the executor chain.
- Luke
Msg is shrt cuz m on ma treo
-Original Message-
From:
ies for each L2.
One thing I left out of the previous post: the difference between fast and slow
behavior was that in the fast case, the buffer selection alternated between two
buffer pages. This was the case only when the preceding statement was a SELECT
and the statement was VACUUM.
- Luke
Ms
UM 3033 MB/s 1597 MB/s
These results do not vary with the order of operations.
Thoughts on the best way to fix the buffer selection algorithm? Ideally,
one page would be used in the buffer cache in circumstances where the table
to be scanned is (significantly?) larger tha
Yay!
This rocks IMO, but I'm a borderline PHB so what do I know ;-)
- Luke
On 2/6/07 9:19 AM, "Magnus Hagander" <[EMAIL PROTECTED]> wrote:
> http://doxygen.postgresql.org is now set up for your browsing pleasure.
> It's synced to ano
l-hackers/2006-09/msg02041.php
Aha - mystery solved - thanks for the clarification.
Block Btree ~= Lossy Btree
- Luke
---(end of broadcast)---
TIP 7: You can help support the PostgreSQL project by donating at
http://www.postgresql.org/about/donate
mited
circumstances like single index organization or the like.
- Luke
> -Original Message-
> From: [EMAIL PROTECTED]
> [mailto:[EMAIL PROTECTED] On Behalf Of Simon Riggs
> Sent: Monday, November 06, 2006 1:51 PM
> To: pgsql-hackers@postgresql.org
> Subject: [HACKERS] Introduci
QL achieve
very high performance for multi-Terabyte business intelligence
databases."
- Luke
---(end of broadcast)---
TIP 4: Have you searched our list archives?
http://archives.postgresql.org
that pattern will only use one disk.
- Luke
---(end of broadcast)---
TIP 1: if posting/reading through Usenet, please send an appropriate
subscribe-nomail command to [EMAIL PROTECTED] so that your
message can get through to the mailing list cleanly
ee of
pipeline parallelism in our executions plans. Each context switch likely
switches a process away from the CPU with local memory, resulting in the
NUMA cache misses.
The answer for us is to bind each process to a CPU. Might that help in
running DBT-2?
- Luke
On 10/10/06 9:40 AM, "
+1
Mark, can you quantify the impact of not running with IRQ balancing enabled?
- Luke
Msg is shrt cuz m on ma treo
-Original Message-
---(end of broadcast)---
TIP 9: In versions below 8.0, the planner will ignore your desire to
:-D
Is that in the release notes?
- Luke
Msg is shrt cuz m on ma treo
-Original Message-
From: Neil Conway [mailto:[EMAIL PROTECTED]
Sent: Thursday, October 05, 2006 02:35 PM Eastern Standard Time
To: Luke Lonergan
Cc: Andrew Dunstan; Tom Lane; Mark Woodward; pgsql-hackers
Create table as select ... Order by ...
Copy to ...
- Luke
Msg is shrt cuz m on ma treo
-Original Message-
From: Andrew Dunstan [mailto:[EMAIL PROTECTED]
Sent: Thursday, October 05, 2006 12:51 PM Eastern Standard Time
To: Tom Lane
Cc: Mark Woodward; pgsql-hackers
0.004s
> sys 0m0.005s
I think you are getting about 40MB/s on your sequential scan of about 5GB of
heap data in this case. I calculate the size of the data as:
3 Integers (12 bytes), one text date field (10 bytes ?) and tuple overhead
(24 bytes) = 46 bytes per
+1
- Luke
On 10/3/06 2:58 PM, "Mark Kirkwood" <[EMAIL PROTECTED]> wrote:
> Tom Lane wrote:
>> Neil Conway <[EMAIL PROTECTED]> writes:
>>> Given the time that has been spent working around
>>> the braindamaged behavior of qsort() on various p
Mark,
On 9/29/06 2:59 PM, "[EMAIL PROTECTED]" <[EMAIL PROTECTED]> wrote:
> Here are results over 64 Mbytes of memory, to ensure that every call is
> a cache miss:
On my Mac OSX intel laptop (Core Duo, 2.16 GHz, 2GB RAM, gcc 4.01):
Luke-Lonergans-Computer:~/strNcpy-perf-
That seems right, there won't be a performance impact unless the warnings are
issued.
- Luke
Msg is shrt cuz m on ma treo
-Original Message-
From: Tom Lane [mailto:[EMAIL PROTECTED]
Sent: Saturday, September 30, 2006 01:48 PM Eastern Standard Time
To: Stephen Fro
quantified benefit, this is certainly a non-starter.
- Luke
---(end of broadcast)---
TIP 4: Have you searched our list archives?
http://archives.postgresql.org
efits of the fixed point versus Numeric are:
- Smaller size of fixed point (less than half)
- Faster arithmetic operations
These should be quantified, so that we can evaluate Money64 as a proposal
and to understand Numeric better.
- Luke
---(end of broadcast)-
D'Arcy,
On 9/28/06 10:12 AM, "D'Arcy J.M. Cain" wrote:
> Numeric has been shown to be as good or better than money in I/O
> operations.
What exactly does that mean in the context of a Datum: "I/O operations"?
- Luke
money64) plus
scale (x) divided by two.
Currently on the TPC-H benchmark, Postgres requires 1.7 times the amount of
internal database storage as what is in the ASCII data file representation.
Oracle and MSFT SQLServer are almost 1:1. Part of this fluff is the 24
bytes of tuple header, part of it i
D'Arcy,
On 9/28/06 9:00 AM, "Luke Lonergan" <[EMAIL PROTECTED]> wrote:
> Which routines implement the money arithmetic?
Ok - so now having read the old documentation and the routine "
backend/utils/adt/cash.c" and the type definition for Cash in "
back
integer arithmetic is not
standard integer operands, right?
Which routines implement the money arithmetic?
- Luke
---(end of broadcast)---
TIP 3: Have you checked our extensive FAQ?
http://www.postgresql.org/docs/faq
Oic - so it's a floating point in an 8 byte int. That probably limits the
speed benefits, no?
- Luke
Msg is shrt cuz m on ma treo
-Original Message-
From: D'Arcy J.M. Cain [mailto:[EMAIL PROTECTED]
Sent: Thursday, September 28, 2006 11:14 AM Eastern Standard Time
To
Though this may be the kiss of death, I favor a 64 bit float version of money.
It's more terse than numeric and a *lot* faster when performing numeric
operations because it would use a cpu intrinsic operand.
- Luke
Msg is shrt cuz m on ma treo
-Original Message-
From: D
27;t, that doesn't mean I'll be interested
> in fixing it. Getting the float datetime code to work is hard enough
> without having a compiler that thinks it can take shortcuts.
How about fixing the compilation so that the routines in adt that are
sensitive to FP optimizations a
e prime culprit.
- Luke
Msg is shrt cuz m on ma treo
-Original Message-
From: Bruce Momjian [mailto:[EMAIL PROTECTED]
Sent: Tuesday, September 26, 2006 11:51 AM Eastern Standard Time
To: Zdenek Kotala
Cc: pgsql-hackers@postgresql.org; Tom Lane; [EMAIL PROTECTED]
Subject:Re:
paper that Ayush Parashar published, he uses the
TPC-H data with some targeted queries that showcase the best use-cases for
bitmap index.
- Luke
---(end of broadcast)---
TIP 6: explain analyze is your friend
ll implement single row error handling, but even then
there should be a selectable behavior to terminate the load on the first
warning/error.
- Luke
---(end of broadcast)---
TIP 4: Have you searched our list archives?
http://archives.postgresql.org
We would help if we do it in an open pgfoundry project.
Bizgres?
- Luke
Msg is shrt cuz m on ma treo
-Original Message-
From: Josh Berkus [mailto:[EMAIL PROTECTED]
Sent: Thursday, September 21, 2006 11:08 PM Eastern Standard Time
To: Jonah H. Harris
Cc: pgsql-hackers
Congrats Jim!
- Luke
Msg is shrt cuz m on ma treo
-Original Message-
From: Jim C. Nasby [mailto:[EMAIL PROTECTED]
Sent: Monday, September 11, 2006 02:12 PM Eastern Standard Time
To: pgsql-hackers@postgresql.org
Subject:[HACKERS] New job
While I'm sitting here i
What version of pgsql?
Recent changes stripped the sort set down considerably in size in external
sort, I'm not sure the same is done if the data doesn't spill to disk.
- Luke
Sent by GoodLink (www.good.com)
-Original Message-
From: Gregory Stark [mailto:[EMAIL PROTE
demic from now on though - the comparisons between
Opteron and Core 2 will all likely be in 64-bit mode from now on.
- Luke
---(end of broadcast)---
TIP 1: if posting/reading through Usenet, please send an appropriate
subscribe-nomail command to
oost in performance. On the Xeon in 64-bit mode, the same regions
of execution will slow down by about 5%.
Postgres benefits automatically from the larger memory addressing of the
64-bit kernel by using the larger I/O cache of Linux.
- Luke
---(end of broadcast)--
ce and Fisheye from
Atlassian, and they are all excellent tools IMO.
OTRS has been OK and fairly malleable.
- Luke
---(end of broadcast)---
TIP 3: Have you checked our extensive FAQ?
http://www.postgresql.org/docs/faq
+!
- Luke
On 8/9/06 11:48 AM, "David Fetter" <[EMAIL PROTECTED]> wrote:
> On Wed, Aug 09, 2006 at 01:58:14PM -0400, Jonah H. Harris wrote:
>> On 8/9/06, Devrim GUNDUZ <[EMAIL PROTECTED]> wrote:
>>> Congratulations for your new job.
>>
>> Sec
uld be done if we threw money and/or people at the
> problem? I'm sure we could come up with both if the end goal
> was having built-in text searching for the next release.
Maybe you've said this before, but why is the current regexp support not
good enough? What kind of r
Cool! Then let's make a stronger claim about the feature: 'data management
using partioning now with transparent insert/update/delete support in addition
to the already proven performance acceleration in previous releases.
- Luke
Sent from my GoodLink synchronized handheld (ww
Fix the visibility issue - there are a number of good ideas on how to
do it, we are in a position to bang it out now IMO.
>> We already have splitting queries among CPUs and machines.
>
> Yes, YOU do. We don't.
Details, details - redefine "We" and it's the
functions
2) MERGE
3) Index only access (new)
4) In-place upgrades
We already have splitting queries among CPUs and machines.
- Luke
---(end of broadcast)---
TIP 3: Have you checked our extensive FAQ?
http://www.postgresql.org/docs/faq
+1
UPDATE/DELETE for CE are a big deal - I really wish we had INSERT too, then
we'd be able to claim "complete" support for partitioning, but this is a big
deal improvement.
- Luke
On 8/3/06 9:30 PM, "Gavin Sherry" <[EMAIL PROTECTED]> wrote:
> A lot of the
We would contribute that if we worked on this.
- Luke
---(end of broadcast)---
TIP 1: if posting/reading through Usenet, please send an appropriate
subscribe-nomail command to [EMAIL PROTECTED] so that your
message can get through to the mailing list cleanly
Bruce,
On 7/29/06 6:31 AM, "Bruce Momjian" <[EMAIL PROTECTED]> wrote:
> Right. People need a patch to test on their workloads, and analysis can
> be done after feature freeze.
Fair enough.
- Luke
---(end of broadcast)-
1 - 100 of 222 matches
Mail list logo
